Oracle EBS R12 Finance BR100: Complete Guide with Sample Template

 Oracle EBS R12 Finance BR100 – Business Requirements and Configuration Document

If you are working as an Oracle EBS R12 Finance Functional Consultant, you have probably heard the term BR100 many times.

But what exactly is a BR100?

What information should be included in a BR100?

How do you prepare a BR100 for an Oracle EBS Finance implementation?

And what does a real consultant-level BR100 look like?

In this article, we will understand Oracle EBS R12 Finance BR100 from a practical implementation perspective, including its purpose, structure, setup requirements, sample business requirements, configuration details, testing considerations, and a sample BR100 template.


What is BR100 in Oracle EBS R12?

A BR100 is commonly used as a functional/business requirements and configuration document in Oracle implementation projects.

It documents the business requirements and translates them into the proposed Oracle EBS solution/configuration.

In simple words:

Business Requirement → Oracle Solution → Configuration → Testing

A BR100 helps the functional consultant document what the business needs and how Oracle EBS will be configured to meet those requirements.

Oracle E-Business Suite Financials is an integrated suite, and implementation depends on factors such as legal entities, ledgers, charts of accounts, calendars, currencies, subledger applications and business requirements.

Why is BR100 important?

A good BR100 provides a common reference point for:

  • Business users
  • Functional consultants
  • Technical consultants
  • Project managers
  • Testers
  • Support teams
  • Business analysts

It can help answer questions such as:

  • What is the business requirement?
  • Which Oracle module is involved?
  • What configuration is required?
  • Which responsibility will be used?
  • What accounting should be generated?
  • What are the dependencies?
  • What assumptions have been made?
  • How will the requirement be tested?
  • Who approved the solution?

Without proper documentation, the same requirement may be interpreted differently by different project teams.

Oracle EBS R12 Finance Modules Covered in BR100

A Finance BR100 can cover multiple Oracle Financial modules.

Common modules include:

1. General Ledger – GL

GL is used for:

  • Journals
  • Accounting periods
  • Ledgers
  • Chart of Accounts
  • Currency
  • Financial reporting
  • Account balances
  • Allocations

Oracle's R12.2 General Ledger documentation includes the accounting cycle and journal-entry processes.

2. Accounts Payable – AP

AP generally covers:

  • Supplier setup
  • Supplier sites
  • Invoice processing
  • Invoice validation
  • Payments
  • Payment methods
  • Accounting
  • AP to GL reconciliation

3. Accounts Receivable – AR

AR generally covers:

  • Customer setup
  • Customer accounts
  • Transactions
  • Receipts
  • Adjustments
  • Credit memos
  • Accounting
  • AR to GL reconciliation

4. Subledger Accounting – SLA

SLA is responsible for the accounting layer between subledger transactions and General Ledger.

It helps determine how accounting entries are generated for supported subledger transactions.

Oracle provides a dedicated Subledger Accounting Implementation Guide for R12.2.

5. E-Business Tax

Tax configuration can include:

  • Tax regimes
  • Tax
  • Tax status
  • Tax rates
  • Tax rules
  • Tax determination

Oracle provides a dedicated E-Business Tax implementation guide as part of R12.2 Financials documentation.


Typical Structure of an Oracle EBS Finance BR100

A practical Finance BR100 can contain the following sections:

  1. Document Control
  2. Business Scope
  3. Business Requirements
  4. Enterprise Structure
  5. Accounting Structure
  6. General Ledger Configuration
  7. Payables Configuration
  8. Receivables Configuration
  9. Subledger Accounting
  10. Tax and Payments
  11. Security and Responsibilities
  12. Reports and Reconciliation
  13. Interfaces and Conversions
  14. Testing Requirements
  15. Assumptions and Dependencies
  16. Open Issues
  17. Sign-Off

Let's understand each section.

1. Document Control

The first section should identify the document.

Sample

FieldExample
Document NameOracle EBS R12 Finance BR100
ProjectABC Finance Implementation
ModuleOracle Financials
Version1.0
Prepared ByFinance Functional Consultant
Reviewed ByFinance Lead
Approved ByBusiness Process Owner
Date28-Sep-2026
StatusDraft

The document version should be updated whenever significant changes are made.


2. Business Scope

This section explains what is included in the project.

Sample Scope

The project will implement Oracle EBS R12 Finance for the following business processes:

  • General Ledger
  • Accounts Payable
  • Accounts Receivable
  • Subledger Accounting
  • Tax
  • Payments
  • Financial reporting
  • Reconciliation

Out of Scope

The following may be excluded:

  • Fixed Assets
  • Cash Management
  • Advanced Collections
  • Projects
  • Treasury

The exact scope depends on the project.


3. Business Requirements

This is one of the most important sections.

Each requirement should have a unique identifier.

Sample

Requirement IDBusiness RequirementModulePriority
FIN-001Company requires monthly accounting periodsGLHigh
FIN-002AP invoices must be validated before accountingAPHigh
FIN-003Supplier payments must use approved payment methodsAPHigh
FIN-004Customer receipts must be accounted in GLARHigh
FIN-005Finance team requires monthly trial balanceGLMedium

A good consultant should avoid vague requirements.

Instead of:

"AP should work properly."

Use:

"The system should allow AP users to enter supplier invoices, validate them, account them and transfer accounting entries to General Ledger."


4. Enterprise Structure

Oracle EBS implementation requires an understanding of the enterprise structure.

A sample organization could look like:

Enterprise

↓

Legal Entity

↓

Operating Unit / relevant organizational structure

↓

Ledger

↓

Business Processes

The exact architecture depends on the R12 implementation design.

Oracle documentation describes the organization model and its relationships as a core part of how Oracle Applications represents complex enterprises.


5. Ledger Configuration

A ledger is a fundamental component of the accounting structure.

Sample Ledger

AttributeExample
Ledger NameABC India Primary Ledger
CurrencyINR
CalendarABC Monthly Calendar
Accounting MethodAccrual
Chart of AccountsABC Corporate COA

The actual values are always project-specific.


6. Chart of Accounts

The Chart of Accounts, or COA, defines the accounting segments used by the organization.

Example

Suppose the company uses four segments:

Company – Department – Account – Product

Example:

01-100-510100-000

Where:

  • 01 = Company
  • 100 = Department
  • 510100 = Account
  • 000 = Product

Another project could use:

Company – Cost Center – Account – Intercompany

There is no single COA structure that is correct for every implementation.


7. General Ledger Configuration

The GL section should document important configurations such as:

Accounting Calendar

Example:

PeriodStart DateEnd Date
Jan-2601-Jan-2631-Jan-26
Feb-2601-Feb-2628-Feb-26
Mar-2601-Mar-2631-Mar-26

Journal Sources

Examples:

  • Manual
  • Payables
  • Receivables
  • Assets
  • Payroll
  • Spreadsheet

Journal Categories

Examples:

  • Purchase
  • Sales
  • Payments
  • Receipts
  • Accrual
  • Adjustment

The actual sources and categories depend on the implementation.


8. Accounts Payable Configuration

The AP section should document the supplier-to-payment process.

Typical AP flow

Supplier Setup

↓

Purchase Order / Non-PO Invoice

↓

Invoice Entry

↓

Invoice Validation

↓

Accounting

↓

Payment

↓

Transfer/Post to GL


Sample AP Requirement

Requirement ID: AP-001

Business Requirement:

The business requires AP users to enter supplier invoices and validate them before accounting.

Proposed Solution:

Oracle Payables will be configured to support invoice entry, validation, accounting and payment processing.

Expected Result:

Only valid invoices should proceed through the configured accounting/payment process.

Oracle provides dedicated R12.2 Payables implementation, reference and user guides.


9. AP Accounting Example

Suppose a supplier invoice is received for office expenses:

Invoice Amount = ₹10,000

Example accounting:

Dr Office Expense ₹10,000

Cr AP Liability ₹10,000

When payment is made:

Dr AP Liability ₹10,000

Cr Bank/Cash ₹10,000

These are simplified examples. Actual accounting depends on the project's setup, tax treatment, SLA rules and transaction configuration.


10. Accounts Receivable Configuration

A typical AR process can be documented as:

Customer Setup

↓

AR Transaction

↓

Transaction Validation

↓

Accounting

↓

Receipt

↓

Receipt Application

↓

GL Transfer

Sample Requirement

Requirement ID: AR-001

Business Requirement:

The business requires customer invoices to be generated and accounted in Oracle Receivables.

Proposed Solution:

Oracle Receivables will be configured to support customer transactions, receipts and accounting.

Oracle's R12.2 documentation includes dedicated Receivables implementation, reference and user guides.


11. AR Accounting Example

Suppose a customer invoice is raised for ₹25,000.

Simplified accounting:

Dr Customer Receivable ₹25,000

Cr Revenue ₹25,000

When the customer pays:

Dr Bank ₹25,000

Cr Customer Receivable ₹25,000

Again, the actual accounting can differ depending on tax, revenue recognition, SLA configuration and other project requirements.


12. Subledger Accounting – SLA

SLA is a very important topic in an Oracle Finance BR100.

A BR100 should document:

  • Accounting method
  • Accounting rules
  • Journal line types
  • Account derivation
  • Sources
  • Supporting references
  • Event classes
  • Accounting entries
  • Transfer to GL

Example

For an AP invoice:

AP Transaction

↓

Accounting Event

↓

SLA

↓

Accounting Entry

↓

GL

The purpose of the design is to ensure that the required accounting is generated consistently based on the configured rules.

Oracle provides a dedicated R12.2 Subledger Accounting Implementation Guide.


13. Tax Configuration

Tax requirements should be documented separately.

A sample requirement could be:

Supplier invoices should calculate applicable tax based on configured tax rules.

The BR100 can document:

  • Tax regime
  • Tax
  • Tax status
  • Tax rate
  • Tax jurisdiction
  • Tax rules
  • Accounting treatment

For India-specific implementations, Oracle also provides a dedicated Financials for India Implementation Guide.


14. Payments

The BR100 should also document payment requirements.

Example:

Payment Methods

  • Electronic
  • Check
  • Bank transfer

Sample Requirement

The organization requires approved supplier invoices to be paid using authorized payment methods.

Configuration should be aligned with the organization's banking and payment process.


15. Security and Responsibilities

A BR100 should document who can access which functionality.

Example

RoleResponsibilityAccess
AP UserPayablesInvoice Entry
AP ManagerPayablesInvoice Approval/Review
AR UserReceivablesTransaction Entry
GL UserGeneral LedgerJournals
Finance ManagerGLReview & Reporting

The exact responsibility/access model should be confirmed with the security team and business.


16. Reports and Reconciliation

A Finance implementation is not complete just because transactions are entering the system.

The business also needs reporting and reconciliation.

Example Reports

GL

  • Trial Balance
  • Account Analysis
  • Journal reports

AP

  • AP Aging
  • Invoice reports
  • Payment reports

AR

  • AR Aging
  • Customer balance
  • Receipt reports

Reconciliation Examples

AP Subledger ↔ GL

AR Subledger ↔ GL

Bank ↔ Cash/GL

These should be documented as business requirements and tested during the project.


17. Interfaces and Conversions

If the project has external systems, document them in the BR100.

Example:

External System

↓

Interface

↓

Oracle EBS

↓

Validation

↓

Accounting

↓

GL

Document:

  • Source system
  • Target system
  • Interface name
  • Frequency
  • File/API format
  • Error handling
  • Reprocessing process
  • Reconciliation

18. Testing Requirements

The BR100 should also provide enough information for the testing team to derive test scenarios.

Example

Requirement: AP invoice should be validated before accounting.

Test Scenario

  1. Create supplier.
  2. Enter invoice.
  3. Validate invoice.
  4. Confirm validation status.
  5. Create accounting.
  6. Review accounting.
  7. Transfer to GL.
  8. Verify GL journal.
  9. Reconcile AP and GL.

Negative Scenario

Enter an invoice with invalid accounting information.

Expected result:

System should prevent or appropriately handle the transaction according to the configured validation rules.


19. Assumptions

Every good BR100 should clearly identify assumptions.

Example:

  • Business will provide approved COA.
  • Business will provide supplier master data.
  • Business will provide customer master data.
  • Tax requirements will be confirmed before configuration.
  • Bank information will be provided by the business.
  • Required responsibilities will be created by the security/technical team.

20. Open Issues

Don't hide unresolved requirements inside the document.

Create a separate table.

Issue IDIssueOwnerStatus
OI-001COA segment structure pendingFinanceOpen
OI-002Tax requirement pendingTax TeamOpen
OI-003Payment method confirmation pendingTreasuryOpen

This makes the BR100 much more useful during implementation meetings.


21. Sign-Off

At the end of the BR100, include approval details.

RoleNameStatusDate
Business OwnerTBDPendingTBD
Finance LeadTBDPendingTBD
Functional LeadTBDPendingTBD
Project ManagerTBDPendingTBD

The purpose is to establish that the documented requirements and proposed solution have been reviewed.


Sample BR100 – End-to-End Example

Let's take a fictional company:

Company

ABC Global Services Pvt. Ltd.

Requirement

ABC wants to implement Oracle EBS R12 Finance.

Modules

  • GL
  • AP
  • AR
  • SLA
  • Tax

Currency

INR

Ledger

ABC India Primary Ledger

Accounting Calendar

Monthly

COA

Company – Department – Account – Product


Example AP Requirement

Business Requirement

ABC requires supplier invoices to be entered, validated, accounted and transferred to GL.

Oracle Solution

Oracle Payables will be used for supplier invoice processing.

Process

Supplier Invoice

→ Invoice Entry

→ Validation

→ Accounting

→ Transfer to GL

→ Journal Review

→ Posting

Expected Accounting

Dr Expense

Cr AP Liability


BR100 vs Functional Design Document

These documents can overlap depending on the organization's methodology, so don't assume every company uses the terminology identically.

A BR100 generally focuses on business requirements and configuration decisions.

A detailed functional design may go deeper into:

  • Detailed functional logic
  • Data mapping
  • Interface logic
  • Reports
  • Extensions
  • Technical dependencies
  • Detailed field-level requirements

The exact documentation methodology is project-specific.


Common Mistakes While Preparing BR100

Mistake 1: Copying Oracle documentation

Don't simply copy Oracle manuals into your BR100.

Use Oracle documentation as a technical reference, then document the project's own requirements and configuration decisions.

Oracle's official R12.2 documentation library provides module-specific implementation guides for Financials, GL, AP, AR, SLA, Tax and other areas.

Mistake 2: Writing only configuration names

For example:

"Ledger created."

This isn't enough.

Instead explain:

"ABC India Primary Ledger will use INR as the functional currency and the approved ABC Corporate Chart of Accounts."

Mistake 3: Ignoring accounting

Finance BR100s should explain the expected accounting wherever relevant.

Mistake 4: Not documenting assumptions

Unknown requirements should be marked as TBD/Open, not silently assumed.

Mistake 5: Not connecting requirements with testing

Each important requirement should be traceable to a test scenario.


BR100 Checklist for Oracle EBS R12 Finance

Before finalizing the document, check:

General

  • Document version available
  • Scope defined
  • Business requirements documented
  • Assumptions documented
  • Open issues documented
  • Sign-off section included

GL

  • Ledger
  • Currency
  • Calendar
  • COA
  • Journal sources
  • Journal categories
  • Period requirements

AP

  • Supplier process
  • Invoice process
  • Validation
  • Accounting
  • Payment
  • Reconciliation

AR

  • Customer process
  • Transaction process
  • Receipts
  • Accounting
  • Reconciliation

SLA

  • Accounting method
  • Accounting rules
  • Account derivation
  • Journal line requirements

Testing

  • Positive scenarios
  • Negative scenarios
  • Accounting validation
  • Reconciliation
  • Integration testing

Downloadable Oracle EBS R12 Finance BR100 Template

If you are an Oracle Finance consultant, creating a reusable BR100 template can save significant documentation time.

A practical template can contain:

Word Template

  • Document Control
  • Business Requirements
  • GL
  • AP
  • AR
  • SLA
  • Tax
  • Security
  • Reports
  • Interfaces
  • Testing
  • Assumptions
  • Open Issues
  • Sign-Off

Excel Workbook

  • COA
  • Ledger
  • AP Configuration
  • AR Configuration
  • SLA
  • Reports
  • Testing
  • Open Issues

You can then customize the template for a specific implementation instead of starting from a blank document every time.


Frequently Asked Questions

What does BR100 stand for?

In Oracle implementation projects, BR100 is commonly used as a business requirements/configuration documentation deliverable. The exact naming and methodology can vary between organizations.

Is BR100 required for every Oracle EBS project?

Not necessarily. Documentation standards are defined by the project or organization.

Who prepares BR100?

Typically, the functional consultant/business analyst prepares or coordinates the document with inputs from business stakeholders and other project teams.

Is BR100 technical or functional?

It is primarily functional/business-oriented, although it can contain technical dependencies where required.

Can BR100 be used for Oracle Fusion?

The documentation methodology and terminology can differ in Oracle Fusion implementations. Don't assume an EBS R12 BR100 can simply be reused unchanged for Fusion.

What modules can be included?

Depending on scope, a Finance BR100 may cover GL, AP, AR, SLA, Tax, Payments, Assets, Cash Management and other financial processes.


Final Thoughts

A good Oracle EBS R12 Finance BR100 is more than a configuration checklist.

It connects:

Business Requirement

↓

Functional Solution

↓

Oracle Configuration

↓

Accounting

↓

Testing

↓

Reconciliation

↓

Business Sign-Off

For an Oracle Finance Functional Consultant, learning to create clear implementation documentation is an important practical skill.

The best BR100 is not necessarily the longest one. It is the one that allows a business user, functional consultant, tester and support consultant to understand what is required, how it is configured, why it is configured that way, and how the result will be validated. 

Comments

Popular posts from this blog

Accounts payable setup in oracle apps EBS

Account Receivables Setup in Oracle R12

Accrual reconciliation when using Accrue Expense Items at Receipt in Oracle EBS R12 or Oracle Fusion.