General Ledger (GL) → Payables (AP) → Receivables (AR) → Cash Management (CM) → Fixed Assets

(FA).
Day 1: Introduction & Core Architecture
 Oracle Fusion Cloud Fundamentals
o Cloud vs On-premise: Key differences with EBS
o Cloud terminology (Offerings, Modules, Legal Entities, Business Units)
o Navigation, landing pages, dashboards, and personalization
 Security & Setup
o Roles: Job, Abstract, and Duty roles
o Functional Setup Manager (FSM): Offerings, Implementation Projects
 GL Introduction
o Basic setups: Ledgers, Currencies, Calendars, Chart of Accounts
o Understanding Enterprise Structures
Day 2: General Ledger (GL) – Functional Mastery
 GL Core Concepts
o Journals: Manual, Automated, Recurring
o Balances, Consolidations, Intercompany processing
 Functional Flows
o End-to-end journal entry, approval, posting
o Period opening/closing
o Inquiry, reconciliation, drill-down
 Configuration
o Ledgers, COA, Legal Entities, Balancing segments
o Defining Journal sources, categories, approvals
Day 3: Payables (AP) – Functional Mastery
 AP Core Concepts
o Suppliers and Supplier Sites
o Invoice processing: Standard, Credit Memo, Prepayments, Expense Reports
 Functional Flows
o Procure-to-Pay overview
o Invoice entry, validation, holds, approval workflows
o Payments: Single, Batch, Electronic, Manual
 Configuration
o Payment Terms, Payment Methods, Bank Account setup
o Payables options and related profiles
Day 4: Receivables (AR) – Functional Mastery
 AR Core Concepts
o Customers and Accounts
o Transaction types: Invoices, Credit Memos, Debit Memos, Receipts
 Functional Flows
o Order-to-Cash overview
o Invoice creation, adjustments, receipt application, reversals
o Refunds and reconciliation
 Configuration
o System and Transaction options
o Receipt classes, remittance, customer profiles
Day 5: Cash Management (CM)
 CM Core Concepts
o Bank accounts, statements
o Reconciliation methods (auto and manual)
 Functional Flows
o Loading bank statements
o Reconciling payments and receipts
 Configuration
o Bank account creation for AP/AR/CM
o Cash Management options
Day 6: Fixed Assets (FA)
 FA Core Concepts
o Asset categories, books, depreciation methods
o Process: Additions, Adjustments, Transfers, Retirements
 Functional Flows
o Asset creation to retirement lifecycle
o Mass additions from AP/Projects
 Configuration
o Asset key flexfields, depreciation methods, asset books setup
Day 7: Integration & End-to-End Implementation Flows
 Integrating the Modules
o Data flow across GL, AP, AR, CM, FA
o Key dependencies (e.g., Subledger Accounting flows, reconciliations)
 Common Implementation Tasks
o Rapid implementation spreadsheets
o Data migration strategies (opening balances, supplier/customer import)
o Troubleshooting and functional diagnostics
 Best Practices
o Functional design documentation
o User training basics
o Navigating Oracle documentation & support resources

EBSR12 vs Fusion Cloud:

1. Deployment Model & Architecture
 EBS R12: Deployed and maintained on your organization's own servers in your data center (on-
premises). All infrastructure, installations, and upgrades are managed internally.
 Fusion Cloud: Delivered as Software-as-a-Service (SaaS) via Oracle's Cloud infrastructure. All
infrastructure, maintenance, backups, and updates are managed by Oracle, accessible via the
web from anywhere.
2. Upgrades & Maintenance
 EBS R12: Upgrades (patches, new releases) must be planned, scheduled, and executed by the
organization's IT team, often involving significant effort and downtime.
 Fusion Cloud: Oracle delivers automatic, regular updates and enhancements. Users benefit
from continuous innovation without manual intervention
3. User Experience & Navigation
 EBS R12: Interface and navigation vary by module and can be more traditional. Customization
often required for cohesive UIs.
 Fusion Cloud: Consistent, modern UI across all modules. Improved navigation, analytics
dashboards, mobile-ready design out-of-the-box
4. Integration & Extensibility
 EBS R12: Integrating with third-party or cloud solutions can be complex due to on-premise
architecture and older integration technologies.
 Fusion Cloud: Designed for seamless integration, provides rich REST/SOAP APIs, connectors,
and Oracle Integration Cloud services for easier hybrid and cloud integrations
5. Customization & Configuration
 EBS R12: Allows wide-ranging customizations with changes in underlying code and database.
This can complicate upgrades.
 Fusion Cloud: Encourages standardized processes with configuration over customization; uses
extensibility tools (like Application Composer, Page Composer) rather than invasive custom
code. This allows for easier upgrades
6. Security & Compliance
 EBS R12: Management is the responsibility of the customer's IT team, including data security,
compliance, and access controls.
 Fusion Cloud: Oracle manages security (physical and logical), compliance, patching, and data
privacy as part of the service. Built-in advanced security features and compliance controls are
regularly audited
7. Scalability
 EBS R12: Scaling requires new hardware or re-architecting internal systems.
 Fusion Cloud: Instantly scalable up or down with cloud resources to suit business demand,
handled by Oracle's infrastructure
8. Mobility & Access
 EBS R12: Access generally requires VPN or secure network setup. Mobile support is limited and
might require extra setup.
 Fusion Cloud: Designed for remote and mobile access. Native support for mobile apps and
responsive browser experience from anywhere with internet

Cloud terminology (Offerings, Modules, Legal Entities, Business Units)

1. Offerings
Offerings in Oracle Fusion Cloud refer to high-level bundles of related business processes and
functionalities that can be enabled during implementation. Each offering groups together related
modules and features, such as Financials, Procurement, Human Capital Management, etc. Selecting
an offering determines which modules, features, and setup tasks are available during configuration.
For example, enabling the "Financials" offering makes modules like Payables, Receivables, and
General Ledger available for setup and use [7].
2. Modules
A Module, sometimes called a Product Family or Functional Area, is a specific application within an
offering that supports a business process. In the context of Financials, modules include Accounts
Payable, Accounts Receivable, General Ledger, Cash Management, and Fixed Assets. Each module
delivers a set of business functions, transactions, and reporting that support specific business tasks
within the offering[7].
3. Legal Entities
A Legal Entity represents an organization recognized by law as a separate entity for financial, tax,
and regulatory reporting. In Fusion Cloud, legal entities:
 Are defined for each business activity that requires legal registration (for example, for tax
reporting or regulated operations).
 Are assigned to ledgers (accounting books), and can contain multiple legal reporting units if
required by country or region.
 Are a core part of the enterprise structure, ensuring proper accountability and financial reporting
4. Business Units
A Business Unit (BU) is a flexible organization within the enterprise that performs one or more
business functions and processes transactions on behalf of one or many legal entities. Key points:
 A business unit is typically aligned with management responsibility and often maps to divisions,
departments, or lines of business.
 Business units can process transactions such as invoices, payments, and purchases, and are
also used as a means to secure transactional data.
 Each business unit is assigned to a primary ledger for accounting.
 Business units facilitate reporting, transaction processing, data security, and reference data
sharing (for example, sharing payment terms or transaction types between units if desired)
Summary Table
Term Oracle Cloud Definition

Offerings Bundled groups of business processes and modules, enabled at implementation (e.g., Financials, Supply
Chain).

Modules Specific functional areas or applications within an offering (e.g., AP, AR, GL, CM, FA in Financials).

Legal Organizations recognized by law, requiring independent reporting and compliance; mapped to ledgers
Entities and used for legal accountability.

Business Organizational units for transaction processing, reporting, and data security, assigned to ledgers; flexible
Units for enterprise structuring.

Introduction & Core Architecture: Navigation, landing pages, dashboards, and

personalization
Navigation
 Home Page: When users sign in, they see a role-based Home Page, which includes icons
(tiles/infolets) for quick access to common functions, reports, and work areas.
 Navigator Menu: This is the primary way to access modules and features. It’s typically found
on the left and organizes all available functions by category (like Payables, Receivables, Assets,
etc.).
 Search Bar: Located at the top, it enables users to quickly locate pages, tasks, transactions, or
reports by entering keywords.
 Recent Items & Favorites: Users can quickly access recently visited pages and pin favorites
for one-click navigation.
 Worklist and Notifications: Centralized notifications and pending approvals ensure that users
never miss important tasks.
Oracle Fusion Cloud navigation is role-based: users see only the modules and functions their
security role allows, promoting both usability and security.

Landing Pages
 Definition: Landing pages provide the starting point for a functional area (such as Payables or
Assets). Each is tailored for the needs of the user’s role.
 Infotiles/Infolets: Landing pages feature interactive tiles summarizing important transactional
data (e.g., invoices pending payment, journal entries requiring attention, asset lifecycle
statuses). Clicking an infotile filters or drills into specific sets of transactions.
 Work Areas: These are sections within landing pages dedicated to managing transactions,
tasks, or analytics for the area. For example, the Assets landing page has infotiles for Additions,
Adjustments, Transfers, Retirements, and Depreciation.
Landing pages are dynamic—numbers and statuses update in real time to help prioritize work.

Dashboards
 Financial Dashboards: Every Oracle Fusion Financials module provides dashboards that
highlight tasks, metrics, and KPIs requiring action or review.
 Personalized Task Tabulation: Dashboards summarize critical tasks, such as invoices to be
approved (in AP), unposted journals (in GL), or pending receipts (in AR).
 Drill-Down Capabilities: Users can drill from high-level KPIs to underlying transactions—
enabling deep analysis directly from the dashboard.
 Embedded Analytics: Real-time analytics embedded in dashboards allow users to perform
analyses, view pre-built reports, and export data.
Dashboards are fully integrated with business intelligence, so users can monitor, analyze, and act
without leaving the work area.

Personalization
 Page Composer: Oracle Cloud uses tools like Page Composer, available through Sandbox, to
allow users and administrators to personalize UI components.
 User-Level Personalization: Individual users can rearrange tiles/infolets, adjust layouts, hide
or display fields, and save search criteria for recurring queries.
 Role-Based Customization: Administrators can tailor landing pages and forms for entire roles
or groups (e.g., show a KPI only to finance managers). Customizations do not affect application
upgrades because they are managed separately from the base application code.
 Responsive Design: All personalizations work across devices (desktop, tablet, mobile).
This flexibility ensures the UI is optimally tailored to maximize user productivity and align with
organizational processes.
Key Takeaways
 Navigation is intuitive, highly visual, and role-driven.
 Landing pages provide real-time, actionable overviews for each business function.
 Dashboards and infotiles offer powerful at-a-glance insights and deep analytics.
 Personalization and customization ensure the interface fits each user’s (or business role’s) needs
without impacting system upgrades.
All these features are standard parts of Oracle Fusion Cloud Financials, designed for efficiency,
usability, and enterprise scalability.
Security & Setup: Roles in Oracle Fusion Cloud
Job Roles
 Definition: Job roles represent specific jobs that users perform within the organization (e.g.,
Accounts Payable Manager, General Accountant, Receivables Manager).
 Purpose: These roles define the access and privileges necessary to perform all tasks associated
with a particular business job.
 Assignment: Job roles are assigned directly to users.
 Examples: Payables Specialist, Cash Manager.
 Customization: Organizations can create custom job roles based on their business
requirements.
Abstract Roles
 Definition: Abstract roles represent broad, commonly shared responsibilities across the
enterprise, independent of a specific job (for example, Employee, Manager, or Contingent
Worker).
 Purpose: Provide access to standard self-service functions, such as managing personal
information or submitting expense reports.
 Assignment: Abstract roles are assigned directly to users. Most users will have at least one
abstract role.
 Examples: Employee, Line Manager, and Project Team Member.
 Customization: Abstract roles can also be created or modified to suit the organization's needs.
Duty Roles
 Definition: Duty roles are logical groupings of privileges required to perform specific tasks or
duties (such as Invoice Processing, Budget Review).
 Purpose: They serve as building blocks for job and abstract roles, granting the necessary
permissions for performing particular functions within the application.
 Assignment: You do not assign duty roles directly to users. Instead, they are inherited by job
roles or abstract roles.
 Examples: Pay Invoices Duty, Asset Adjustments Duty.
 Customization: You can create, edit, and copy duty roles to align with your organization’s
security requirements.
Role Inheritance and Privilege Hierarchy
 Job and abstract roles inherit duty roles—either directly or indirectly. This means a user
assigned a job or abstract role automatically receives the necessary duty role permissions.
 This hierarchical structure ensures robust and granular security while making role
management flexible and scalable.
Key Points
 Job roles and abstract roles are directly assigned to users.
 Duty roles are never directly assigned to users; they are included within job roles and abstract
roles.
 This approach enables effective segregation of duties, compliance, and a standardized way to
manage access across all Oracle Fusion Cloud Financials modules.
These role definitions and their usage ensure that access to Oracle Fusion Cloud Financials is secure,
both from a business process and data perspective, while simplifying user administration and
upholding best practices as described in Oracle’s official documentation.

Functional Setup Manager (FSM): Overview

Functional Setup Manager (FSM) is the core application within Oracle Fusion Cloud that provides a
guided, end-to-end process for implementing and maintaining Oracle Fusion Applications. FSM
delivers a standardized way to configure offerings, perform and track setup tasks, and migrate setup
data between environments.
Offerings
 Definition: An offering is a collection of business processes grouped together for
implementation—such as Financials, Procurement, or Human Capital Management.
 Enablement: Only those offerings relevant to your organization's Oracle Cloud subscription can
be enabled. Enabling an offering also enables its core functional areas and allows you to opt into
optional functional areas and features.
  Configuration: You access and configure offerings from the "Offerings" work area within FSM.
Here, you choose which business processes (offerings) and which functional areas/features to
implement, based strictly on your enterprise requirements.
 Examples: If you select the Financials offering, you gain access to modules like Payables (AP),
Receivables (AR), General Ledger (GL), Cash Management (CM), and Fixed Assets (FA).
Implementation Projects
 Definition: An implementation project in FSM is a project-driven collection of setup tasks
required to implement a selected offering (and its functional areas).
 Creation: You create an implementation project by selecting an offering and then choosing the
relevant functional areas and features for your project. Each project automatically generates a
structured list of all setup tasks needed for the offering's functional scope.
 Task Assignment & Tracking: Implementation projects allow you to:
o Assign setup tasks to specific users (based on their expertise and security roles).
o Set due dates and track progress on each setup task.
o Monitor dependencies and prerequisites among tasks, ensuring setup happens in the
correct order.
 Multiple Offerings: Oracle recommends creating separate implementation projects for each
offering for manageability and ease of migration.

Typical Implementation Steps with FSM

1. Plan: Identify which offerings (business processes) your organization needs and evaluate their
functional areas and features.
2. Configure: Enable/opt in to the required offerings, functional areas, and features.
3. Setup: Use FSM to enter setup data for each enabled offering/area via the generated task lists
in your implementation project. Assign tasks as needed to functional team members.
4. Deploy: After validation, export/import setup data to move from test (sandbox) to production
environments.
5. Maintain: Update setup data or opt into new features as your business needs change.
Key Points
 FSM centralizes and standardizes the entire setup and implementation process for
Oracle Cloud applications.
 You must have appropriate security roles (e.g., Functional Setups User, Application
Implementation Consultant) to access FSM and manage offerings and projects.
 Offerings determine what business processes you can implement; implementation projects
manage the actual configuration steps and team collaboration.
This workflow ensures a reliable, auditable, and efficient approach to deploying Oracle Fusion Cloud
Financials in line with best practices set out in Oracle's official documentation.

Ledgers
A ledger is the central record-keeping structure in Oracle Fusion Cloud General Ledger.
 The ledger defines your accounting currency, chart of accounts, accounting calendar, and
accounting method.
 Each accounting setup requires at least one primary ledger. You may also define additional
secondary ledgers or reporting currencies as required by your business or statutory needs.
 Ledgers serve as containers for all your journal entries and balances, providing the basis for
financial reporting.
 You assign legal entities to a ledger, so transactions are recorded per local and international
requirements.
 The configuration of a ledger is often referred to as the "4 Cs": Chart of Accounts, Calendar,
Currency, and (Accounting) Convention/Method.
Currencies
 Currencies define the unit of measure for financial transactions and reporting within your
ledger.
 The ledger’s functional currency is its base currency for recording transactions, but Oracle
Fusion supports multicurrency operations—allowing for transactions and reports in multiple
currencies as required.
 Currencies are identified by their ISO codes (e.g., USD, EUR, INR).
  You must define all the currencies that will be used for entering and reporting transactions in
Oracle Fusion.
 Once a currency code is used in the ledger, it cannot be changed as it becomes a reference for
many transactions across modules.
Calendars
 The accounting calendar determines the start and end dates of your fiscal periods—monthly,
quarterly, weekly, or based on any pattern that fits your organization.
 All journals and accounting transactions posted to the ledger reference these calendar periods
for precise financial reporting.
 The calendar controls the opening and closing of periods for transaction entry, ensuring all
activity falls within valid accounting windows.
 Each calendar is assigned to a ledger and is also shared across subledgers for consistency in
period controls.
 You define one or more calendars in the “Manage Accounting Calendars” setup task, specifying
period names, frequencies, adjusting periods, and so on.
Chart of Accounts
 The Chart of Accounts (COA) is a flexible structure with segmented accounts to classify and
record transactions for the organization.
 Each ledger is assigned a COA, which organizes financial data into segments (e.g., company,
department, account, product) using value sets for valid code combinations.
 The Chart of Accounts structure defines the:
o Number of segments.
o Sequence/order of segments.
o Segment labels (e.g., balancing segment, natural account).
o Value sets (defining which values are permitted for each segment).
 At the instance level, you can assign value set assignments for segments and build unique
hierarchies for reporting.
 Your COA is essential for supporting reporting requirements, security, and enforcing accounting
controls.
 Changes to the structure are tightly controlled to ensure consistency in financial reporting and
analysis.
Summary Table
Setup Purpose and Key Points
Component

Ledgers Foundation for accounting, defines currency, calendar, COA, and

method per entity.

Currencies Defines transaction and reporting units; supports multiple currencies

per ledger.

Calendars Regulates fiscal periods for journals and reporting; controls period
status.

Chart of Segmented classification for transactions; structure supports granular

Accounts reporting.

In Oracle Fusion Cloud Financials, these foundational setups—ledgers, currencies, calendars, chart of
accounts—must be carefully considered and configured to ensure correct, compliant, and efficient
financial operations across your enterprise.

What Are Enterprise Structures?

Enterprise structures in Oracle Fusion Cloud represent your organization’s legal, managerial, and
functional operating model. Correctly defining these structures is essential for compliance, internal
control, management reporting, and efficient financial operations.
Key Components
1. Enterprise:
The highest-level organization in Fusion Cloud Applications, representing the deploying
company/corporation. The enterprise record stores company-wide information such as the name
and headquarters location.
 2. Legal Entities:
Distinct legal organizations registered to do business and comply with laws and regulations.
Each legal entity is linked with one or more ledgers for statutory reporting and tax requirements.
3. Business Units:
Logical divisions within the enterprise that perform specific business functions (e.g., sales,
operations, finance). Business Units process transactions, are pivotal for data security, and
support management autonomy. A business unit can process transactions for one or more legal
entities and is typically aligned with organizational strategy and profit-and-loss responsibility.
4. Divisions and Departments:
o Divisions represent lines of business, regions, or product families.
o Departments are the lowest organizational unit, usually representing teams or cost
centers.
5. Charts of Accounts:
The account structure with multiple segments (e.g., company, department, cost center, account)
that classifies and organizes all financial transactions.
6. Ledgers:
The primary accounting record for legal entities, where transactions are recorded using the
assigned chart of accounts, currency, and fiscal calendar.
7. Reference Data Sets:
Mechanisms allowing sharing of reference data (e.g., payment terms, transaction types) across
multiple business units and ledgers, providing efficiency and consistency.
Business Process Model for Enterprise Structures
Theprocess of establishing enterprise structures involves:
 Defining the enterprise and its legal entities.
 Setting up legal jurisdictions and authorities for tax and regulatory compliance.
 Creating business units for transactional processing and operational control.
 Designing the financial reporting structures—charts of accounts, ledgers, and related
hierarchies.
 Configuring facilities and locations as needed for inventory and asset management.
 Defining reference data sharing to streamline setup and maintenance across units.
Guidelines and Tools
 Enterprise Structures Configurator: An interview-based tool in Oracle Fusion that guides
users through defining the enterprise, legal, management, and operating structures. It ensures
that the design meets statutory, managerial, and business needs.
 During configuration, consider your enterprise’s industry, need for centralized or decentralized
control, reporting requirements, and compliance obligations.
 You can assign multiple classifications to organizations (e.g., treating an organization as both a
department and a project unit) to maximize flexibility.
Practical Examples
 A multinational company may have several legal entities (one for each country), multiple
business units by line of business, with divisions and departments tied to these units.
 Reference data like payment terms might be shared across many business units, while other
data remains unit-specific.
Summary Table
Component Purpose

Enterprise Top-level record for the company organization

Legal Entities Legally recognized organizations, responsible for compliance

and reporting

Business Units Transaction-processing units aligned with management

structures

Divisions/ Logical separation for business lines or teams

Departments

Chart of Accounts Structure to classify and report all transactions

Ledgers Record accounting entries per legal/compliance rules

 Reference Data Enable data-sharing across business units and entities
Sets

Oracle Fusion Cloud’s enterprise structure design enables you to model even the most complex
organizations, supporting both legal requirements and the management’s analytical needs—all while
maintaining robust security, reporting, and operational controls.

Day 2: General Ledger (GL)

Oracle Fusion Cloud GL Core Concepts
1. Journals
 Manual Journals: Users can enter, edit, and post manual journal entries directly, supporting a
range of accounting scenarios.
 Automated Journals: Journals can be generated automatically from subledgers (like Payables
or Receivables) and imported into GL.
 Recurring/Allocation Journals: For repeating or pattern-based entries, users set up recurring
journal batches or allocation formulas to streamline periodic processes.
2. Accounting Cycle
Key steps in the GL accounting process include:
 Opening Accounting Periods: Unlocking periods for transaction entry and posting.
 Journal Entry: Creating standard, statistical, or intercompany entries (including corrections and
approvals).
 Importing Journals: Bringing in data from external sources or subledgers. Errors during import
are corrected and the process re-run as needed.
 Posting Journals: Approving and posting journals, which updates the balances in real time.
 Period Closing: Finalizing accounting periods after completion of all journal entries and
reconciliations[11].
3. Intercompany and Consolidations
 Intercompany Processing: Supports creation of journals and balances between
interconnected companies or subsidiaries within the enterprise.
 Consolidations: Enables the combination of financial results from multiple subsidiaries into
group-level ledgers, using integrated tools and rules [11].
4. Multidimensional Analysis & Balances Cube
 Essbase Balances Cube: Oracle Fusion GL includes native multidimensional OLAP capabilities.
As journals are posted, the system updates the “balances cube,” a pre-aggregated structure
allowing users to view and analyze balances instantly at any level—across legal entities,
accounts, cost centers, time periods, and more.
 Real-time Analytics: Reporting is immediate, as the cube refreshes with every entry,
eliminating the need for separate data warehouse jobs or delayed updates. This enables
powerful drill-down and slice-and-dice analysis directly within the application [12][13].
5. Embedded Reporting & Analytics
 Financial Reporting Center: Built-in dashboards, KPIs, and inquiry tools empower users to
monitor balances, review activity, and generate statutory and management reports seamlessly.
 Drill-Down & Account Monitor: Click through balances to see transactional detail or statistical
analysis by any chart of accounts segment.
 Dashboards: Personalized pagelets and dashboards provide summaries (e.g., unposted
journals, exceptions, variances), embedded with real-time analytics [12][13].
6. Subledger Accounting Integration
 Subledger Accounting (SLA) captures detailed business events in AP, AR, and other modules,
transforms these into legally compliant accounting representations, then posts summarized or
detailed journals to General Ledger. This linkage ensures granular control (for both US GAAP and
IFRS compliance) and robust auditability [12].
7. Compliance & Security
 Segregation of Duties: Fine-grained roles govern who can create, approve, and post journals
or close periods.
 Audit Trails: Automatic audit logs track all entries, approvals, and changes, ensuring
transparency and compliance.
8. Key Functional Innovations in Fusion Cloud
  Immediate Data Visibility: No need to run batch jobs to update balances after postings—
everything is visible in real time.
 Flexible Accounting Structures: Multiple ledgers, currencies, calendars, and charts of
accounts can be managed centrally, supporting complex multinational requirements.
 Configurable Approval Workflows: Approvals for journals and other transactions are fully
configurable and auditable.
 Reference Data Sharing: Security and reference data (like approving hierarchies, account
segment values) are shareable across business units and ledgers [14][15].
In summary: Oracle Fusion Cloud General Ledger brings centralized, real-time, multidimensional
accounting with advanced reporting/analytics, tightly integrated subledger accounting, and
configurable, highly secure processes—streamlining the entire accounting lifecycle and enabling
powerful, compliant financial management for even the most complex global organizations.

Balances
 Real-Time Balance Updates: In Oracle Fusion Cloud GL, account balances are updated
instantly with every journal posting. This is enabled by the balances cube (Essbase), which
provides immediate, multidimensional access to financial data without batch processes.
 Multidimensional Analysis: Balances can be analyzed across any segment of the Chart of
Accounts (such as company, cost center, department), various periods, currencies, and ledgers.
Users can drill down from summary balances directly to transaction details.
 Account Monitor & Inquiries: Tools like the Account Monitor allow users to track balances,
compare actual-to-budget, and analyze activity trends. Pre-built dashboards and inquiries let
you review balances, variances, and exceptions in real time without IT involvement.
 Financial Reporting: The Financial Reporting Center and Smart View integration enable user-
friendly, ad hoc reporting and statutory report generation, leveraging current balance data.
Consolidations
 Purpose: Financial consolidations aggregate the transactional and balance data of multiple
subsidiaries, legal entities, or business units into higher-level reporting ledgers for group-wide
financial and statutory reporting.
 Types of Consolidation:
o Multi-Ledger Reporting: Oracle Fusion allows you to maintain multiple ledgers (primary,
secondary, reporting). You can consolidate actuals across ledgers using reporting currency
or secondary ledger features.
o Oracle Financial Consolidation and Close Cloud (FCCS): For advanced consolidation
(such as intercompany eliminations, multiple GAAP/IFRS reporting), Oracle recommends
integrating with FCCS. However, core generalized ledger consolidation tools are available
within Fusion GL for basic to intermediate needs.
 Key Features:
o Consolidation Journals: Create, approve, and post journals specifically for consolidation
adjustments, such as foreign currency translations or elimination of intercompany profits.
o Hierarchical Rollups: Use chart of account hierarchies to roll up balances from detail to
summary entities or parent companies.
o Automated Processes: Period-end routines automate data transfer, translation, and
elimination steps, with full audit trails of all consolidation actions.
 Reporting: Consolidated reports can be generated directly in the Financial Reporting Center,
and consolidation status is visible through dashboards.
Intercompany Processing
 Overview: Intercompany processing in Oracle Fusion GL enables organizations to record,
match, and reconcile transactions (such as sales, services, or financing) that occur between
separate legal entities or business units within the same enterprise.
 Intercompany Accounts Setup: Define Chart of Account segments and rules for intercompany
receivable and payable accounts in the ledger setup. Configure balancing relationships between
business units/legal entities to automate accounting entries.
 Transaction Flow:
o Initiation: Transactions can be initiated in subledgers (e.g., Payables, Receivables) or
directly in GL.
 o Balancing: The system automatically generates due-from/due-to entries to keep all legal
entities in balance, ensuring that intercompany transactions are reflected on both sides.
o Approval & Matching: Intercompany transactions may go through approval workflows
and must be matched/reconciled by both parties before final posting.
o Elimination: At consolidation time, elimination entries are created to remove the effect of
intercompany transactions from consolidated financial statements.
 Monitoring & Reconciliation: Dedicated reports and dashboards help track open
intercompany items, perform aging analysis, and reconcile outstanding balances between
entities. Audit trails ensure transparency and compliance.
Key Points
 Balances: Always current, multidimensional, with robust drill-down and instant analytics.
 Consolidations: Built-in tools for basic needs; advanced features available via integration;
streamlined adjustment and elimination processes; real-time consolidated reporting.
 Intercompany: Automated, rule-based, transparent, and fully auditable processing and
reconciliation across multiple legal entities.
This architecture ensures accurate statutory and management reporting, compliance with accounting
standards, and operational efficiencies for complex, multi-entity organizations using Oracle Fusion
Cloud Financials.

End-to-End Journal Entry Flow in Oracle Fusion Cloud GL

1. Journal Entry Creation
 Manual Journal Entry:
Users (with appropriate job roles, like General Accountant) navigate to the Journals work area
and select "Create Journal." They complete the journal header (name, category, period,
description), then add journal lines, specifying relevant chart of accounts segments, amounts,
currencies, and any supporting references or attachments.
 Automated/Imported Journals:
Journals may be generated by subledgers (e.g., Payables, Receivables) or imported from
external systems using predefined templates or FBDI (File-Based Data Import). These journals
appear in the GL as unposted.
 Validation:
Oracle Fusion automatically validates journal entries upon save—checking debits equal credits,
valid account combinations, open periods, and required supporting data. Errors are displayed to
the user for correction.
2. Journal Approval Workflow
 Workflow Initiation:
Depending on system configuration, journals may require approval before posting. Approval
rules are highly configurable via the BPM (Business Process Management) worklist.
 Routing:
When a journal is submitted for approval, the workflow engine routes it to the designated
approver(s) (such as a Finance Manager) based on predefined criteria—amount, source, cost
center, etc.
 Approval/Reject/Request Information:
Approvers receive notifications and can approve, reject, or request more information. Status
updates are visible in the journal work area and via notifications. All actions are logged with
audit details.
 Delegation:
Approvers may delegate tasks to others if needed, maintaining workflow continuity.
3. Journal Posting
 Ready for Posting:
Once approved (if approval is required) and validated, journals have a status of "Ready to Post"
or "Unposted."
 Posting:
Users with the proper role initiate the "Post Journals" process (manually, scheduled, or as part of
an automated cycle). The system posts the journal, instantly updating GL balances.
  Balance Update:
With posting, the balances cube is refreshed in real-time. Posted journals become part of
permanent accounting records.
 Drill-Down & Reversal:
Posted journals are available for inquiry/reporting and direct drill-down. If a posted journal needs
to be reversed (due to error or reclassification), the system supports single or batch reversals
with appropriate accounting period controls.
4. Key Controls and Features
 Status Tracking:
Every journal displays its status (Draft, Incomplete, Awaiting Approval, Approved, Ready to Post,
Posted).
 Period Control:
Journals must be entered and posted to open periods only, ensuring strong financial period
governance.
 Security and Audit Trails:
Every step—entry, edit, approval, posting, reversal—is logged for comprehensive auditing.
 Attachments and Supporting Data:
Users can attach documents (such as spreadsheets, invoices, or explanations) to journals for
supporting evidence and compliance.
 Error Handling:
Invalid journal entries are rejected during validation or posting, with detailed error messages
and guided correction.
 Bulk/Spreadsheet Entry:
For large volumes, journals can be entered or uploaded via spreadsheet integrations, with full
validation and workflow.
This comprehensive process ensures control, compliance, and transparency for all journal activity in
Oracle Fusion Cloud General Ledger—supporting internal policies and external audit requirements.

Period Opening and Closing in Oracle Fusion Cloud GL

1. Accounting Periods and Calendar
 The accounting calendar defines the fiscal periods—monthly, quarterly, or as needed.
 Each ledger is assigned a calendar, and all subledgers aligned to it use the same period
structure.
2. Opening an Accounting Period
 Purpose: Opening a period allows users to post journal entries and subledger transactions for
the selected period.
 Who Can Open Periods: Only users with the appropriate security roles (typically General
Accountant or GL Manager) can open or change the status of accounting periods.
 How to Open:
o Navigate to the Manage Accounting Periods work area.
o Select the desired ledger and accounting calendar.
o Change period status to Open for the relevant accounting period.
 Multiple Periods: You may open multiple periods simultaneously (e.g., for year-end
adjustments), or keep only one open to tighten control.
3. Managing Period Statuses
 Period statuses include:
o Never Opened: Period has not been used yet.
o Open: Period is available for new journal and subledger transaction postings.
o Future Entry: Transactions may be entered but not posted until the period is opened.
o Closed: Period is closed to all additional postings.
o Permanently Closed: No further changes allowed—irreversible (used for compliance).
4. Closing an Accounting Period
 Purpose: Ensures all relevant transactions for the period are complete and posted; prevents
further changes.
 Pre-Closing Checks: Before closing, perform these steps:
o Verify Subledger Close: Ensure Payables, Receivables, Assets, etc., are closed for the
period (so their journals are transferred and posted to GL).
 o Post All Journals: Confirm all GL journals have been posted.
o Reconcile Balances: Use tools like account inquiries, balance reports, exception
dashboards to reconcile ledger balances and ensure accuracy.
o Review Errors: Correct or remove any journals in error or incomplete status.
 How to Close:
o Navigate to the Manage Accounting Periods page.
o Select the ledger/calendar and target period.
o Change status from Open to Closed.
o System checks for unposted journals or open subledger periods and displays warnings if
issues remain.
5. Reopening a Period
 If corrections are needed: Accounting managers (with the required role) can reopen a closed
period except those marked as "Permanently Closed."
 This enables limited, controlled corrections or additional posting before final closure.
6. Period Lockdown and Control
 Security and Audit: All changes in period status are logged, with workflow notifications and
audits for compliance.
 Automated Controls: Organizations can configure controls such as:
o Prevent posting to prior periods.
o Limit number of open periods.
o Require subledger closure before GL can be closed.
 Notification and Reporting: The system generates notifications and reports on status of
periods, exceptions, and unresolved items.
7. Best Practices
 Maintain a clear period-close checklist tailored to your enterprise (subledger close,
reconciliation, posting, reporting).
 Use dashboards for period-close status tracking and exception analytics.
 Leverage smart view and Financial Reporting Center for final period results and statutory
reports.
In summary:
Oracle Fusion Cloud GL offers a structured, role-based, and auditable process for opening and closing
accounting periods. Robust status controls, workflow notifications, integration with subledgers, and
real-time analytics all ensure secure, efficient, and compliant financial period management.

Period Opening and Closing in Oracle Fusion Cloud GL

1. Accounting Periods and Calendar
 The accounting calendar defines your fiscal periods (monthly, quarterly, etc.).
 Each ledger is assigned an accounting calendar; subledgers align with the same period structure
to ensure synchronized reporting and controls.
2. Opening an Accounting Period
 Purpose: Opening a period allows journal entries and subledger transactions for that period.
 Permissions: Only users with designated security roles (e.g., General Accountant, GL Manager)
can manage period statuses.
 Steps:
o Navigate to the Manage Accounting Periods work area.
o Select the relevant ledger and period.
o Change the period status to Open.
 Multiple periods can be open if needed (for year-end processing), or the enterprise can restrict
the number of open periods for tighter control.
3. Managing Period Statuses
 Never Opened: Not yet available for postings.
 Open: Period is active for all transactions.
 Future Entry: Allows transaction entry for future periods, but posting is restricted until the
period is opened.
 Closed: Prevents new postings, locking the period to changes.
 Permanently Closed: Final closure that cannot be reversed, often for audit purposes.
4. Closing an Accounting Period
 Purpose: To ensure all activity for the period is captured and prevent further changes.
 Pre-close Checklist:
o Subledger Close: Confirm that all subledger periods (AP, AR, FA, etc.) are closed and their
journals transferred to GL.
o Post All Journals: Verify that all journals (manual, subledger, imported) are posted.
o Reconciliation: Review balances, resolve discrepancies, and use inquiry tools and
exception dashboards.
o Error Resolution: Clean up any incomplete or invalid journals.
 Steps:
o Go to the Manage Accounting Periods page.
o Select the target ledger and period.
o Change the status to Closed.
o The system may warn about unposted journals or open subledgers.
5. Reopening Periods
 If corrections are needed after closing (but before permanent closure), authorized users can
reopen the period.
 After necessary corrections, repeat the closing steps to re-close the period.
6. Controls, Security, and Audit
 All changes to period status are logged for compliance and audit.
 Automatic controls can enforce prerequisites, such as requiring all subledgers to be closed
before closing GL.
 Role-based security ensures only authorized personnel can open or close periods.
7. Reporting and Best Practices
 Dashboards and period status reports provide real-time updates on the open/close process,
exceptions, and outstanding items.
 Oracle recommends using a standardized period-close checklist, leveraging dashboards, and
monitoring with Financial Reporting Center or Smart View for end-of-period review.
Summary:
Oracle Fusion Cloud GL delivers a secure, auditable, and streamlined framework for managing
accounting periods. Robust controls across period statuses, integration with subledgers, real-time
reporting, and clear user roles ensure that financial close cycles are accurate, efficient, and
compliant.

GL Inquiry
 Account Inquiry:
Oracle Fusion GL provides robust tools for users to view current and historical balances, journal
activity, and account analysis. The Account Monitor allows you to search for accounts (using any
chart of accounts segment) and review balances, movements, and key metrics over different
periods or entities.
 Real-Time Data:
All inquiries display up-to-date balances and transactional details, leveraging the balances cube
for instant presentation.
 Flexible Search Options:
Users can filter and search by ledger, entity, cost center, account, project, period, or other COA
segments, providing highly granular inquiries.
GL Reconciliation
 Reconciliation Workbench:
The GL offers reconciliation work areas for period-end and ongoing activity. These include tools
for reconciling trial balances, identifying discrepancies between subledgers and general ledger,
matching account entries, and clearing suspense or intercompany accounts.
 Automated Exception Detection:
The system highlights out-of-balance scenarios, inconsistencies, and variances automatically.
 Subledger Reconciliation:
Automated transfers from AP, AR, and FA to GL enable straightforward subledger-to-GL
reconciliation, using pre-built reports and dashboards to ensure that all subledger journals are
posted and reconciled with GL balances.
  Account Reconciliation:
Period-end processes include reviewing account activity for accuracy, validating account
balances, and reconciling intercompany or suspense accounts.
GL Drill-Down
 Drill-Down from Summaries:
In all inquiry and report views, users can click balances, amounts, or journal references to "drill
down" to increasingly detailed levels:
o From balance to journal lines
o From journal lines to source (subledger) transactions
o From summary totals to individual transactions or even supporting documents
 Integrated Analytics:
Dashboards and queries often embed drill-down links, so decision-makers can investigate causes
of variances, identify root issues, or review supporting evidence within a few clicks.
 Subledger Integration:
Drill-downs enable moving directly from GL journal entries into subledger transaction details
(such as invoices in Payables or receipts in Receivables), streamlining audits and helping with
discrepancy resolution.
 Attachments & Audit:
When drilling down to a transaction, users can view any attached documents, approvals, or
comments logged at each step for complete audit transparency.
Key Points
 GL Inquiry and reconciliation tools empower users to monitor account activity, investigate
issues, and ensure financial data integrity in real time.
 Drill-down features deliver complete transaction visibility from high-level balances to underlying
source documents and approvals.
 System dashboards, reports, and work areas are all designed to support interactive querying,
reconciliation, and audit trails—supporting compliance, efficiency, and management oversight.
Together, these features ensure that Oracle Fusion Cloud General Ledger offers unparalleled
transparency, reconciliation accuracy, and ease of inquiry for both operational users and auditors.

1. Ledgers
 Definition:
A ledger is a complete set of accounting records that includes a shared chart of accounts,
accounting calendar, currency, and accounting method.
 Configuration Steps:
o Specify the ledger’s functional currency (primary currency for recording transactions).
o Assign an accounting calendar (defines periods, quarters, fiscal years).
o Associate the chart of accounts (structure for classifying all transactions).
o Select the accounting method (such as US GAAP, IFRS, or enterprise custom rules).
 Multiple Ledgers:
Organizations often configure multiple ledgers if they need to support different statutory
requirements for legal entities in multiple countries or separate accounting rules.
2. Chart of Accounts (COA)
 Definition:
The COA is a segment-based coding structure, defining how financial data is categorized and
reported.
 Configuration Steps:
o Define the number and names of segments (e.g., company, department, account, product,
cost center).
o Assign value sets to each segment, controlling valid entries (must be centrally managed
to maintain data integrity).
o Designate required segment labels:
 Primary Balancing Segment (typically "Company" or "Legal Entity")
 Natural Account Segment (classifies the nature of the transaction: asset, liability,
revenue, expense)
 Cost Center Segment (for tracking costs, if needed)
o Configure cross-validation rules to govern valid code combinations.
  COA Structure Updates:
Changes to the COA are tightly controlled due to their major impact on reporting and data
integrity.
3. Legal Entities
 Definition:
Legal entities are business organizations registered for legal, tax, or statutory purposes and are
responsible for compliance and financial reporting.
 Configuration Steps:
o Define each legal entity and enter required registration, tax, and reporting details.
o Assign legal entities to primary ledgers for accounting and statutory compliance.
o Attach legal reporting units as necessary (for establishments or branches required by
specific jurisdictions).
o Create relationships between legal entities and operating units (such as business units) to
process transactions on behalf of the entity.
4. Balancing Segments
 Purpose:
Balancing segments ensure all financial transactions can be balanced (debits = credits) at the
required organizational level—such as entity, company, or fund. This is crucial for statutory and
management reporting.
 Typical Setup:
o At least one segment in the COA is labeled the Primary Balancing Segment (commonly
"Company" or "Legal Entity").
o Optionally, define up to two Secondary Balancing Segments for more granular
balancing requirements (e.g., "Fund" or "Region").
 Assignment:
o During ledger configuration, assign which segment will serve as the balancing segment.
o When entering transactions, Oracle Fusion automatically generates intercompany or
intracompany balancing lines if a transaction affects multiple balancing segment values.
Key Configuration Relationships
 Legal entities are associated with ledgers for statutory reporting.
 Ledgers use the defined COA. The primary balancing segment in the COA links back to
entities for correct account balancing and reporting.
 Business units and other operational structures process transactions and are mapped to the
legal and accounting structure as configured.
Configuration Best Practices
 Carefully plan the COA structure and balancing segment assignment for current and future
organizational needs.
 Ensure complete and accurate legal entity records for compliance and reporting.
 Choose ledgers and accounting calendars based on statutory and management reporting
requirements per jurisdiction.
 Maintain strict control on changes to the COA, ledger, and balancing configuration to uphold
financial integrity.
These configurations establish the backbone of accounting and compliance in Oracle Fusion Cloud
Financials. Proper setup ensures robust, compliant, and efficient financial management for
organizations of any complexity.

1. Defining Journal Sources

 Purpose:
Journal sources identify the origin of each journal entry in the GL—for example, whether an entry
was created manually in the GL, imported from Payables, Receivables, Assets, or uploaded from
external systems.
 Key Configuration Steps:
o Navigate to the "Manage Journal Sources" setup task under the General Ledger functional
area.
o Use predefined sources (such as Payables, Receivables, Manual, Spreadsheet) or create
custom sources for external integrations, as needed.
o Enter required attributes and enable/disable relevant options:
  Control whether journals from this source can be imported using unique keys.
 Specify the non-business day rule for effective dating of the journals.
 Set the source to require approval (covered in detail below).
 Enable references, which allows referencing transactions for audit or reconciliation.
 Activate or deactivate the source as required for transaction entry.
o Each source is uniquely named and can be referenced in reporting, auditing, SLA rules, and
approval policies.
2. Defining Journal Categories
 Purpose:
Journal categories provide a way to classify and group journal entries according to their business
purpose (such as Accrual, Payments, Adjustments, Revaluations, etc.).
 Key Configuration Steps:
o Navigate to the "Manage Journal Categories" setup task.
o Define new categories as needed, providing a unique name, key, and description.
o Set options such as:
 Whether the category should be available for manual journal entry, or restricted to
use by subledgers or integrations.
 Assign reversal criteria sets to automate how and when journals of this category
should be reversed (for example, next day, next period, same period, or require no
reversal).
o Categories help streamline processing, ease filtering and reporting, support SLA rules, and
control the reversal and approval behavior for each category.
3. Setting Up Journal Approvals
 Purpose:
Journal approvals ensure that only validated, authorized journal entries are posted to the ledger,
enforcing control and compliance over financial reporting.
 Prerequisite Setup:
o Approval must be enabled at two levels: first, at the ledger level using the "Specify
Ledger Options" task (enable journal approval), and second, at the journal source level
using the "Manage Journal Sources" task (mark that journals from this source require
approval).
 Approval Rule Configuration:
o Navigate to the Business Process Management (BPM) Worklist or "Manage Approval Rules"
area for the FinGLJournalApproval task.
o Create or edit rules according to business requirements, which may include:
 Sending journals above a certain amount for approval.
 Requiring one or more supervisory levels.
 Routing by ledger, source, category, or user.
 Automatically approving low-risk or system-generated journals.
o The approval workflow enables routing to designated approvers, supports notifications,
allows for comments or attachments, and keeps a full audit trail of the approval process.
o Approvers can approve, reject, or request more information directly from their worklist
notifications.
4. Additional Notes
 Integration:
Journal sources and categories can be referenced within reporting, audit, and Subledger
Accounting (SLA) rules, enabling comprehensive control and visibility over all journal entries.
 Compliance and Audit:
All configuration changes and approval actions are tracked and logged as part of Oracle’s
standard audit process.
 User Access:
Proper functional roles (such as General Accountant, GL Implementation Consultant) are
required to manage these setups and approval configurations.
Summary:
Oracle Fusion Cloud GL provides a structured, secure, and auditable approach for controlling the
entire lifecycle of journal entries through precise configuration of sources, categories, and approval
hierarchies. This ensures each transaction is traceable to its origin, grouped for efficient processing,
and posted only after appropriate review and authorization—delivering full compliance and business
integrity.

Day 3: Payables (AP)

Suppliers
 Definition:
In Oracle Fusion Cloud Payables, a supplier is any party (individual, corporation, or other entity)
from which your organization purchases goods or services.
 Supplier Record:
Each supplier has a centralized profile that contains key details such as:
o Supplier name and tax identification.
o Business classification (e.g., Corporation, Individual, Government).
o Contact information (addresses, phone numbers, email).
o Banking and payment information.
o Tax reporting and withholding details.
o Certifications and compliance data as required.
 Supplier Types:
Suppliers can be created for different purchase transactions, including standard suppliers, one-
time suppliers, or third-party payees.
 Supplier Lifecycle Management:
Suppliers are registered through a controlled process, which can include:
o Online self-service registration (with optional approval workflow).
o Internal creation by procurement or AP personnel.
o Ongoing maintenance of data (e.g., updating addresses, compliance statuses).
Supplier Sites
 Definition:
Supplier sites represent the specific physical locations (addresses) where business is conducted
with the supplier. Each site defines how and where purchasing, invoicing, and payment activities
should occur for the supplier.
 Supplier Site Attributes:
o Each supplier can have one or more sites—such as "Headquarters," "Branch Office," or
"Remittance Address."
o Sites are linked to operating units (business units in Fusion Cloud), meaning different
business units can transact with the same supplier independently.
o Each site includes payment, invoice, and ordering settings that override general supplier
defaults for that site:
 Payment terms, methods, and bank accounts.
 Tax applicability and reporting rules.
 Invoice processing options (e.g., matching requirements, holds).
 Site Usage:
Supplier sites dictate the operational flow for:
o Where purchase orders are sent (“Purchasing” site).
o Where invoices are received and processed (“Payment” site).
o Where physical goods are delivered (“Ship-To” site).
o Where payments are remitted (“Remittance” site).
Supplier and Site Controls
 Approval and Security:
Creation and updates to suppliers and their sites may require approval workflows. Security roles
determine who can create, update, or view supplier records.
 Auditability:
Every change to supplier or site data is automatically logged, providing an auditable record for
compliance and fraud prevention.
  Supplier Qualification and Compliance:
Fusion Cloud supports qualification processes (questionnaires, certifications) to assess and
approve suppliers based on your organization’s compliance requirements.
 Supplier Hierarchies and Relationships:
You can manage relationships between parent suppliers and their subsidiaries, or map “related
suppliers” for combined reporting or compliance screenings.

Centralized Master Data

 Single Source of Truth:
Suppliers and their sites are centrally managed and shared across all relevant Oracle Cloud
applications (Payables, Procurement, Sourcing, etc.), ensuring consistency and reducing
maintenance.
 Data Sharing:
Reference data sets allow for sharing suppliers/sites across business units or ledgers, but you
can restrict access for sensitive suppliers if needed.
Summary:
Oracle Fusion Cloud Payables provides a centralized, flexible, and secure structure for managing
suppliers and supplier sites. Each supplier has a holistic profile supporting compliance, payment, and
procurement needs. Supplier sites enable nuanced control over where transactions (invoices,
payments, orders) are sent and managed, with robust security, audit, and compliance features built
in—all aligning with official Oracle documentation and best practices.

Standard Invoices
 Definition:
A standard invoice is the most common type of invoice and represents an amount owed to a
supplier for goods or services received.
 Process:
o Created by entering invoice details (supplier, supplier site, amount, currency, invoice date,
descriptions).
o May be manually entered, imported (via spreadsheet or integration), or generated from
matched purchase orders or receipts.
o Matching:
 PO-matched invoices are linked to a purchase order, helping automate validation and
ensure accuracy.
 Non-PO invoices are entered directly if not related to a purchase order.
o Validation:
 System checks for common errors (dates, duplicates, matched quantities/amounts,
open periods).
 Holds are placed if discrepancies are detected.
o Approval:
 Workflows route invoices for approval based on amount, supplier, or business rules.
o Payment:
 Once validated and approved, standard invoices are selected for scheduled payment
runs.
Credit Memos
 Definition:
A credit memo is issued by the supplier and represents a reduction in the amount owed,
typically to correct an overcharge or return of goods.
 Process:
o Entered similarly to standard invoices, referencing the related invoice and/or purchase
order.
o The amount is entered as a negative value, reducing the liability.
o Subject to validation and approval workflows.
o When applied, credit memos are matched to open standard invoices, reducing their
balance due.
Prepayments
 Definition:
A prepayment is an invoice paid in advance to a supplier—before goods or services are received.
 Types:
o Temporary Prepayments: Later applied to standard invoices from the supplier.
o Permanent Prepayments: Not applied; typically used for deposits or advances not expected
to offset future invoices.
 Process:
o Create a prepayment invoice (select type "Prepayment") with supplier and amount details.
o Pay the prepayment according to payment terms.
o When the supplier submits a standard invoice, apply the prepayment amount (fully or
partially) to reduce the invoice due.
o System tracks the unutilized prepayment balance for future application or reconciliation.
Expense Reports
 Definition:
Expense reports are invoices submitted for employee-incurred business expenses, like travel or
meals.
 Process:
o Employees enter expense details using self-service solutions; managers or AP users review
and approve.
o System performs validation (policy compliance, duplicate check, receipt matching).
o Approved expenses are imported as invoices in Payables, associated with the employee
supplier record.
o Paid either through payroll (if integrated) or via the standard invoice payment process.
Common Features Across Invoice Types
 Invoice Validation:
All invoices must pass validation (invoice date, amount, supplier, period, matching, tax rules).
 Approval Workflow:
Configurable rules route invoices for approval as required.
 Holds and Releases:
Automatic or manual holds (e.g., quantity, price, policy non-compliance) must be addressed
before payment.
 Audit and Compliance:
Attachments, supporting documentation, and full audit trails are maintained for every invoice.
 Reporting and Inquiry:
Inquiry tools and reports enable users to track status, approval, payment, and accounting
history for all invoices.
In summary:
Oracle Fusion Cloud Payables provides robust, configurable processes for managing a wide variety of
invoice types—ensuring proper validation, compliance, and automation for standard supplier invoices,
credit memos, prepayments, and employee expense reports. Each flows through centralized controls,
approval workflows, and systematic reconciliation, aligned with best practices and controls outlined in
official Oracle documentation.

Procure-to-Pay (P2P) Functional Flow: Oracle Fusion Cloud

The Procure-to-Pay flow automates the entire lifecycle from identifying the need for goods/services
through payment to suppliers. It integrates Procurement, Purchasing, Receiving, Accounts Payable,
and General Ledger.
Step-by-Step Overview with Examples and Flow
Ste Description Example Scenario
p

1 Requisition Creation Jane (employee) requests laptops for her department using the self-service portal. The
requisition includes item, quantity, need-by date.

2 Requisition Approval Manager Bob reviews and approves the request based on company policy and budget.
 3 Purchase Order (PO) Procurement converts the approved requisition into a purchase order to Supplier XYZ,
Creation specifying agreed price and delivery terms.

4 PO Approval & PO is reviewed, then electronically sent to Supplier XYZ.

Dispatch

5 Goods/Services When laptops arrive, the receiving team enters a “receipt,” confirming the quantity
Receipt and condition in Fusion Cloud.

6 Supplier Invoice Supplier XYZ emails an invoice referencing the PO. AP team enters it in Oracle
Payables, matching it with PO and receipt for a 3-way match.

7 Invoice Validation & System validates the invoice. Any differences (e.g., overbilling) trigger a hold for
Approval review.

8 Payment Processing Once validated and approved, Oracle Payments issues payment (e.g., via bank
transfer) to Supplier XYZ on the due date.

9 Accounting & All financial entries from invoice and payment processes are transferred to General
Posting to GL Ledger for reporting and reconciliation.

Key Features and Controls

 3-Way Matching: Oracle Fusion Cloud automatically matches Purchase Order, Receipt, and
Invoice. Only when all align within defined tolerances is payment processed, ensuring financial
control.
 Role-Based Access: Employees, managers, procurement agents, and AP clerks each have
tailored dashboards, notifications, and task lists.
 Workflow and Approvals: Each stage—requisition, PO, invoice—can be controlled by robust,
configurable approval workflows.
 Real-Time Analytics: Dashboards and infolets provide at-a-glance views of outstanding
requisitions, unreceived goods, unpaid invoices, etc.
 Audit and Compliance: Each transaction, approval, and change is logged for audit traceability
and compliance reporting.
Example Scenario – Laptop Procurement
1. Jane, a business analyst, logs into Oracle Fusion Cloud and creates a requisition for 10 laptops.
2. The requisition is routed to Bob, her manager, who approves it after reviewing the business
case.
3. The Procurement specialist converts this requisition to a purchase order, which is automatically
routed to the Procurement Manager for approval.
4. Upon approval, the system sends the PO to XYZ Laptops Inc.
5. After delivery, the receiving dock staff record the receipt in Fusion Cloud, confirming all 10
laptops have arrived in good shape.
6. XYZ Laptops Inc. emails a system-generated invoice; the AP team enters or imports it, adding
links to the corresponding PO and receipt.
7. Oracle validates the invoice (does the quantity, price, and item match the PO & receipt?) and
routes it for payment approval.
8. On the payment due date, Oracle Payments automatically issues payment and posts the
accounting entries.
Illustrative Functional Flow
 Employees and Procurement interact in the early stages (requisition to PO).
 Suppliers interface from PO receipt through invoice submission.
 Accounts Payable manages invoice matching, validation, and payment.
 General Ledger receives summarized accounting for financial reporting.
This end-to-end P2P cycle in Oracle Fusion Cloud ensures strong internal controls, real-time visibility,
and seamless integration across procurement and finance—all aligned to official Oracle
documentation and leading practices for enterprise efficiency and compliance [16][17][18][19].

1. Invoice Entry
Invoice entry initiates the Payables process. Users can enter invoices manually, import them via
integrated tools, or automate entry through invoice imaging solutions.
Pathways for Invoice Entry:
  Manual Entry: AP users enter invoice details in the Payables work area—keying in supplier,
supplier site, invoice date, amounts, lines, tax, and reference documents (like PO number).
 PO-Driven Entry: Invoices referencing a Purchase Order pre-fill many fields (supplier, PO
number, line details).
 Spreadsheet/Template Import: High-volume invoices can be uploaded in bulk using standard
FBDI templates.
 Automated Imaging: Supplier invoices received via email can be scanned and processed by
Oracle Intelligent Document Recognition, reducing manual entry.
Example:
Suppose a supplier emails a $12,000 invoice for delivered office chairs. The AP Specialist locates the
supplier, inputs invoice data, references the related PO, and attaches the PDF.
2. Invoice Validation
After entry, the system performs automatic validation to ensure the invoice is accurate and ready
for further processing.
Validation Checks Include:
 Mathematical Accuracy: Checks that line and total amounts are correct.
 Supplier and Site Validity: Confirms the supplier and associated site are active and correctly
set up.
 PO and Receipt Matching: For purchase order-based invoices, performs 2-way (PO), 3-way
(PO and receipt), or 4-way (inspection) match as configured.
 Duplicate Detection: Prevents posting of duplicate invoices based on supplier, invoice
number, and amount.
 Open Period Check: Ensures the invoice date is in an open accounting period.
 Tax Determination: Automatically calculates and validates applicable taxes.
3. Invoice Holds
If validation encounters errors or mismatches, the system places the invoice on hold. Holds prevent
payment until the issue is resolved.
Common Hold Types:
 Quantity/Price Hold: PO invoice quantity or price does not match the PO or receipt within
allowed tolerances.
 Distribution Variance Hold: GL code on invoice does not match PO or expected allocation.
 Missing Receipt Hold: Goods have not been received, but invoice is submitted.
 Policy/Compliance Hold: Manual hold due to non-compliance or fraud/segregation of duties
rules.
Example:
 If an invoice for 120 office chairs is received but the system only shows receipt of 100, a
quantity hold is placed until the discrepancy is resolved.
Resolution Path:
AP users navigate to the Holds tab, review issues, consult supporting documents or stakeholders, and
release the hold once corrected (e.g., by adjusting receipt quantities, correcting prices, or uploading
missing documentation).
4. Invoice Approval Workflows
Once validated (and any holds released), invoices may require approval before payment. Oracle
Fusion Cloud provides robust, configurable approval workflows.
Workflow Features:
 Rule-Based Routing: Invoices are routed to approvers based on amount, supplier, department,
expense type, or custom policies.
 Sequential or Parallel Approvals: Approval chains can be set up in specific sequences or in
parallel, per business requirements.
 Automatic vs. Manual Approvals: Low-value invoices may auto-approve; high-value or
exception items may demand multi-level or executive approval.
 Notifications and Audit Trail: Approvers are notified via their Worklist and Dashboard; all
approval actions are logged for compliance and audit.
 Delegation: Users can delegate approval authority during absence, per preset controls.
Typical Flow Example:
flowchart TD
A[Validated Invoice] --> B{Approval Needed?}
B -- Yes --> C[Route to Approver (Manager/Dept Head)]
 B -- No --> D[Invoice Scheduled for Payment]
C --> E{Approved?}
E -- Yes --> D
E -- No/Queried --> F[Returned for Correction/Hold]

5. End-to-End Illustration: Invoice Processing Example

1. Entry: Supplier’s invoice for contract services is received. AP Specialist enters supplier data,
amount, and attaches the contract.
2. Validation: System checks PO match, supplier validity, and amount; flags that invoice amount
exceeds PO by 10%.
3. Hold: Price hold is automatically placed pending manager review of the discrepancy.
4. Hold Resolution: Manager confirms the scope change, updates the PO, and releases the hold.
5. Approval: Invoice exceeds $10,000, so it is routed to the department head for approval.
6. Payment: Upon approval, the invoice is scheduled for payment in the next payment run, with
the accounting distribution posted based on PO and company policy.
Visual Summary
graph TD
IE[Invoice Entry] --> IV[Invoice Validation]
IV --> |If errors| IH[Invoice Holds]
IH --> |Corrected| IV
IV --> |Passed validation| AW[Approval Workflow]
AW --> |Approved| P[Payment Scheduled]
AW --> |Rejected| IE

Key Takeaways
 Invoice processing in Oracle Fusion Payables is structured, controlled, and flexible.
 Validation and holds ensure only accurate, authorized invoices are paid, eliminating errors
and fraud.
 Approval workflows provide transparent, auditable, rule-driven paths for all invoices,
supporting corporate policy and regulatory compliance.
 All actions—from entry to payment—are logged, with supporting documents and clear audit
trails accessible from within the system.
These capabilities safeguard financial operations, reinforce control and compliance, and support
efficient, error-resistant accounts payable management—following official Oracle documentation and
leading practices.

1. Single Payments
Definition:
A single payment is a payment to a single supplier for one or more selected invoices, processed
individually (rather than part of a batch).
Process:
 AP user selects one or more invoices due for a supplier.
 Initiates a payment process, choosing payment method (check, electronic, wire, etc.).
 Reviews and confirms payment details (supplier banking info, amount, date).
 System generates payment, updates invoice status to "Paid," and posts accounting entries.
Example:
A consultant submits a one-time invoice for $2,500. The AP user selects the invoice and processes a
single payment via direct bank transfer.
Flow Diagram
[Select Invoice(s)] → [Initiate Single Payment] → [Review & Confirm] → [Payment Sent] → [Update Status]

2. Batch Payments (Payment Process Requests)

Definition:
Batch payments (Payment Process Requests, PPR) allow AP users to pay multiple invoices for one or
more suppliers in a single process—streamlining bulk and recurring payments.
Process:
 AP user defines payment criteria (due date, supplier, business unit, amount).
 Initiates the Payment Process Request (PPR), which selects qualifying invoices.
  System groups payments by supplier, consolidates per banking and company policy rules.
 User reviews/edit batch before final approval (can exclude invoices, prioritize, or split).
 System generates payment instructions and produces output files for electronic transfer or
check printing.
 Payments are issued, invoices marked as "Paid," and postings sent to GL.
Example:
AP schedules a mid-month payment run for all utility suppliers with invoices due by the 15th; 30
invoices across 10 suppliers are consolidated and paid.
Batch Payment Process Flow
flowchart TD
A[Define Payment Batch Criteria] --> B[System Selects Invoices]
B --> C[Review/Edit Selections]
C --> D[Approve Payment Batch]
D --> E[Generate Payments (Check/Electronic)]
E --> F[Mark Invoices Paid & Post to GL]

3. Electronic Payments
Definition:
Electronic payments (e.g., EFT, ACH, SEPA) transfer funds directly from your organization’s bank
account to suppliers’ bank accounts using payment files generated by Oracle Fusion Cloud and
submitted to banks.
Key Elements:
 Payment Methods: EFT, ACH, wire transfer, SEPA credit transfer, and more. Each method
follows defined formatting and approval processes.
 Bank Integration: Oracle produces payment files in required bank formats, supporting
standard protocols.
 Security: Sensitive payment and banking info is encrypted and access-controlled.
 Reconciliation: Automated status updates confirm successful or failed transmissions with
return files from banks.
Example:
 Payroll vendor invoices are set to be paid by ACH. Oracle generates the NACHA-format file,
which is uploaded to the bank for direct payments to vendors.
Diagram: Electronic Payment Processing
[Invoices Selected]
↓
[Create Payment Instructions]
↓
[System Generates Electronic Payment File]
↓
[File Sent to Bank]
↓
[Bank Processes Payments]
↓
[Confirmation/Failure Reported Back to Oracle]

4. Manual Payments
Definition:
Manual payments are created when a payment is made outside Oracle (e.g., emergency wire in bank
portal, hand-written check). These must be recorded in Oracle Cloud for reconciliation and audit.
Process:
 AP user selects the paid invoice(s) and enters payment details (date, method, reference,
clearing account).
 System marks invoices as paid, posts entries accordingly.
 Manual payments can be reconciled later when the bank statement is imported.
Example:
 The CFO issues a same-day wire transfer for a critical supplier to avoid late delivery. The AP
team records a manual payment entry in Oracle Cloud, linking it to the supplier invoice.
5. Key Controls and Features
  Payment Methods & Formats:
Payment methods and banking formats are configurable per supplier/site, payment purpose, and
region.
 Approval Workflows:
Payment batches and large/sensitive payments utilize workflow approvals, with audit trails and
role-based security.
 Bank Account Setup:
Each business unit can have multiple bank accounts for different types of payments.
 Payment Holds/Stops:
Ability to stop, void, or cancel payments if errors or disputes arise.
 Reconciliation:
Payments automatically feed into Cash Management for reconciliation with bank statements.
End-to-End Payments Example
1. AP schedules a PPR to pay all due supplier invoices.
2. System selects eligible invoices, consolidates payments by supplier/bank.
3. Payment batch is reviewed and approved by the Finance Manager.
4. Oracle generates an EFT file; file is sent to the corporate bank.
5. Bank processes payments; Oracle updates invoice and payment status based on bank return
file.
6. Completed payments post to GL and become available for reconciliation in Cash Management.
Visual Summary
graph TD
IS[Invoice Selection] --> PP[Payment Processing]
PP --> |Manual| MP[Enter Manual Payment]
PP --> |Single| SP[Single Payment]
PP --> |Batch| BP[Batch Payment (PPR)]
SP & BP & MP --> PM[Pmt Instruction/Approval]
PM --> PO[Payment Output/File]
PO --> BK[Bank Processing]
BK --> RS[Reconcile & Post to GL]

Summary:
Oracle Fusion Cloud Payables supports a full suite of payment methods: single, batch, electronic, and
manual. Each method is tightly controlled, configurable, and integrated with approval workflows,
bank integration, and audit/reporting tools. This ensures secure, efficient, and compliant payment
operations for organizations of any size—all according to official Oracle documentation and enterprise
best practices.

Configuration: Payment Terms, Payment Methods, Bank Account setup

1. Payment Terms
Definition:
Payment Terms determine when and how much your organization pays its suppliers. They govern due
dates, discount periods, and partial payment options.
Configuration Steps:
 Navigate to the Manage Payment Terms setup task.
 Define the payment term name (e.g., “Net 30,” “2/10 Net 30”).
 Specify parameters:
o Days until due (e.g., 30, 45).
o Discount terms: Set early payment discounts (for example, “2% discount if paid within 10
days, net due in 30”).
o Installments: Configure if the payment will be split across multiple dates or percentages.
 Assign default payment terms to suppliers or supplier sites. These can always be overridden on
the invoice if needed.
Example Table of Common Payment Terms:
 Term Description System Behavior
Name

Net 30 Due in 30 days Due date = Invoice date +

30 days

2/10 Net 2% disc. in 10 days, 2% discount if paid within 10

30 else 30 days

Net 45 Due in 45 days Due date = Invoice date +

45 days

Illustration: Payment Terms Impact on Invoice

sequenceDiagram
Supplier->>AP System: Submit Invoice (Invoice Date: Aug 1)
AP System->>Payment Scheduler: Review Payment Terms (Net 30)
Payment Scheduler->>AP System: Payment Due Date = Aug 31
AP System->>Supplier: Payment Released on Due Date

2. Payment Methods
Definition:
Payment Methods specify how payments are disbursed to suppliers (e.g., electronic transfer, check,
wire, etc.).
Configuration Steps:
 Go to Manage Payment Methods in the setup menu.
 Define payment method codes (e.g., “Check,” “EFT,” “Wire”).
 Select how each method will be initiated and formatted (manual, batch, electronic).
 Set default payment methods for suppliers at supplier, supplier site, or invoice level.
Assigning Payment Methods:
 Global methods: Available for use across the enterprise.
 Supplier/site-specific: Configure defaults based on geography, supplier preference, or
regulation.
Example:
 A vendor in the U.S. prefers checks, while an overseas supplier requires wire transfer.
o For U.S. supplier: Set “Check” as the default method in supplier site profile.
o For overseas supplier: Set “Wire” (configured with the appropriate file format for the bank).
Diagram – Where Payment Methods Apply:
graph TD
SUPPLIER[Supplier Record]
SITE[Supplier Site]
INV[Invoice]
SUPPLIER --> SITE
SITE --> INV
SITE -->|Default Payment Method| INV
INV -->|Override if needed| PAYMTHD[Payment Process]

3. Bank Account Setup

Definition:
Bank Accounts in Payables are used as disbursement accounts from which payments are made to
suppliers. Accounts are set up centrally and assigned to business units.
Configuration Steps:
 Use the Manage Bank Accounts task.
 Define:
o Bank (name, address, branch details)
o Bank Branch (routing codes, location)
o Bank Account (account number, currency, owner, usage)
 Assign the bank account to relevant business units for making payments.
 Map bank accounts to payment methods (e.g., EFT payments use Account 1234; checks use
Account 5678).
  Configure security: Only users with the correct roles can view, assign, or initiate payments from
this bank account.
Key Attributes:
 Disbursement Account: Account used by Payables to issue outbound payments.
 Multi-currency: Support for accounts in different currencies as required by the business unit or
transaction.
 Payment Document Association: Assign check stocks, EFT, or wire templates according to
account and payment method.
Example Setup:
Bank Account Usage Payment
Name Number Methods

HSBC 123456789 Disburseme Check, EFT

nt

CitiBank 987654321 Disburseme Wire

nt

Illustration – Payment Account Flow:

flowchart TD
INV[Payables Invoice]
PPR[Payment Process Request]
BKSEL[Bank Account Selection]
PMMTH[Payment Method]
PYMT[Payment Issued]
INV --> PPR
PPR --> BKSEL
BKSEL --> PMMTH
PMMTH --> PYMT

Combined Example: Automated Payment Workflow

1. AP team enters an invoice for Supplier ABC.
2. The supplier site defaults to “Net 30” terms, “EFT” payment method, and maps to the business
unit’s default bank account.
3. Payment Process Request batches due invoices, selects the correct disbursement account and
method, and generates an EFT file.
4. The payment is issued to the supplier, invoice is marked paid, and all accounting entries are
posted to GL.
Key Takeaways
 Payment Terms automate due dates, cash flow, and discount management—customizable for
supplier relationships.
 Payment Methods standardize and control how funds are released, ensuring compliance with
supplier preferences and regulatory rules.
 Bank Account Setup provides secure, flexible, and auditable management of business bank
accounts for payment processing.
 All setups are centralized, role-based, and support segregation of duties, audit trails, and flexible
overrides at supplier/site/transaction level.
These configurations underpin automated, compliant, and efficient payment operations in Oracle
Fusion Cloud Payables, ensuring control, flexibility, and alignment with enterprise and supplier
requirements.
Configuration: Payables options and related profiles

1. Payables Options
Payables Options in Oracle Fusion Cloud define system-wide defaults and controls that govern how
the Payables application processes transactions. These settings impact invoice, payment, accounting,
tax, and reporting behavior for each business unit.
Configuration Path
 Accessed via: Setup and Maintenance → Financials → Payables → Manage Payables Options for
each business unit.
Key Sections and Example Settings
 Section Example Settings Impact/Behavior

Invoice Allow document sequencing, Controls invoice numbering, matching comes (2-way, 3-
invoice matching, default terms way), default invoice type, tax rules

Payment Pay alone flag, payment currency, Determines if each invoice is paid separately, restricts
payment approval currency, mandates approval before payment

Accounting Accrual vs. cash basis, account Configures accounting methods, default liability accounts,
segments defaults tax and freight account tracking

Tax Default tax codes, tax rounding Automates tax processing, compliance, and calculation
rules methods

Supplier Supplier numbering, hold options, Automates supplier creation, controls holds for new/invalid
invoice creation suppliers

Withholding / Default tax groups, threshold Enables and configures automatic withholding/certificate
Deductions amounts thresholds

Reporting Employee reporting flag, PDF Determines reporting formats and employee payment
output options methods

Example Table: Payables Options for US Business Unit

Option Value Description

Accrual Method Accrual Uses accrual accounting for liabilities

Allow Manual Yes Users can create manual (unbatched)

Payments payments

Payment Currency USD Payments default in USD for the business unit

Default Pay Group Regular Assigns invoices to regular payment batches

by default

Apply Withholding After Taxes are applied and reported after payment
Tax Payment

Default Liability 20100-AP- Auto-populates invoice distributions if blank

Account US

Diagram: Payables Options Influence

flowchart TD
INVOICE[Invoice Entry]
APPROVAL[Approval Needed?]
PAYMENT[Payment Processing]
ACCOUNT[Accounting/GL Entry]
TAX[Tax Calculation]
REPORT[Reporting/Compliance]
PO[Payables Options]
INVOICE -- Payables Options set default fields, matching --> PO
PAYMENT -- Payables Options set currency, approval req. --> PO
ACCOUNT -- Payables Options define posting accounts --> PO
TAX -- Tax rules and rounding from --> PO
REPORT -- Output format, tax, withhold from --> PO

2. Related Profiles
Profiles (profile options) are parameters that further refine user/session/application behavior,
supplementing Payables Options with additional granularity. Profiles can be set at the application,
responsibility, user, or site level.
Common Payables-Related Profiles
Profile Option Example Behavior Controlled
Value

AP: Allow Prepayment Application Yes/No Whether users can apply prepayments
automatically
 AP: Enable Invoice Validation Yes/No Enables/disables workflow for invoice validation
Workflow

AP: Automatic Tax Calculation Yes/No Enables default tax calculation during invoice entry

AP: Invoice Match Option 2-way/3-way Default match required for supplier invoices

AP: Default Payment Method EFT/Check Sets system/user-level default for payments

AP: Employee Access to Payables Yes/No Allows employees to see their expense
Invoices reimbursement status

Where to Configure:
 Use the Manage Profile Options in FSM (Functional Setup Manager).
 Set at Site, Application, Responsibility, or User level—enabling controls and exceptions as
needed.
Illustration: Profile Option Hierarchy
graph LR
S(Site Level)
A(Application Level)
R(Role/Responsibility Level)
U(User Level)
PRO[Profile Option Lookup]
S --> PRO
A --> PRO
R --> PRO
U --> PRO

Settings at a more specific level (user) override more general levels (site).
3. Combined Example: How Payables Options and Profiles Work Together
Scenario:
The AP Manager wants invoices for a subsidiary processed in EUR, with 3-way matching, and all
payments require approval.
 In Payables Options for that business unit:
o Set Invoice Currency to EUR
o Enable 3-way matching
o Check Require Payment Approval
 In Profiles:
o At user level, set AP: Allow Prepayment Application to "No" for new users
o At responsibility level, set default payment method to "Wire"
With these settings, all users:
 Default to EUR invoices
 Must complete 3-way match on PO invoices
 Cannot pay an invoice until approved
 Only authorized users can manually pay or apply prepayments
4. Best Practices and Controls
 Audit and Security: All changes to Payables Options and key profiles are logged and subject to
audit tracking.
 Segregation of Duties: Limit access to critical option/profile changes to ensure compliance
and prevent fraud.
 Centralized Control: Use business unit-level setup to align options precisely with local or legal
requirements.
Visualization: Payables Configuration Impact
flowchart TD
IO(Payables Options) -- Sets --> EN(Entry & Processing Rules)
PO(PROFILE OPTIONS) -- Refines/Overrides --> EN
EN(Entry & Processing Rules) -- Determines ---> OUT(System Behavior per Business Unit)

Summary
Payables Options provide the foundation for standardized, compliant, and efficient invoice and
payment processing per business unit. Related profile options add targeted control, flexibility, and
segregation capabilities for users and policies.

Day 4: Receivables (AR) – Functional Mastery

1. Customers and Customer Accounts
Definition:
A customer is any individual or organization to whom your business sells goods or services. Each
customer can have multiple accounts and address sites, tailored for specific business units or
transaction types.
Key Structures:
 Customer Profiles: Capture credit terms, payment cycles, statement frequency, and risk level
defaults.
 Account Sites: Designate bill-to, ship-to, and statement addresses.
 Contacts: Maintain specific contact points for customer billing, disputes, or marketing.
Example:
Global Tech Ltd. is a customer. They have two account sites: New York (bill-to) and Chicago (ship-to).
Their profile class requires invoices to be due in 30 days with a $50,000 credit limit.
2. Receivables Transactions
Types:
 Invoices: Charges for goods/services delivered (e.g., $10,000 for IT consulting).
 Credit Memos: Reduce receivables for returns or overcharges (e.g., $1,000 returned goods).
 Debit Memos: Additional charges (e.g., late payment fees).
 Chargebacks: Create new receivable for a disputed amount.
 On-Account Credits: Credits not immediately applied to a transaction.
Transaction Lifecycle:
1. Enter/create transaction (manually, via AutoInvoice, or API).
2. Assign customer, transaction type, date, and items/services.
3. Validate and approve transaction.
4. Post to the General Ledger.
Flow Example – Invoice Creation:
[Select Customer]
↓
[Enter Invoice Details]
↓
[Validate & Approve]
↓
[Post to GL]

3. Receipts (Collections/Payments)
Definition:
A receipt is a record of payment received from a customer, which is then applied to one or more
invoices.
Receipt Types:
 Standard Receipts: Cash, check, or bank transfer payments.
 Miscellaneous Receipts: Non-customer revenue (e.g., rebates).
 Automatic Receipts: For recurring payments, the system generates scheduled receipts.
Processing Steps:
1. Enter receipt (select customer, method, and amount).
2. Apply to open transactions (manual or auto-apply based on remittance advice).
3. Confirm and clear receipt through bank reconciliation.
4. Handle exceptions (short/over payments, unapplied cash).
Example:
A customer pays $10,000 covering two invoices of $6,000 and $4,000—the receipt is split and applied
accordingly.
Illustrative Diagram – Applying Receipt
[Receipt Entry]
↓
[Apply to Invoices]
↓
[Confirm/Remit/Bank Clear]

4. Adjustments and Credit Management

Adjustments:
Manual changes to open receivable amounts due to issues like short payments, errors, or customer
disputes, always tracked for audit.
Credit Memos:
Issued when a customer returns goods or services are canceled.
Example:
If an invoice of $5,000 is partially returned ($1,000), a credit memo is created for $1,000, reducing
the customer's outstanding balance.
Credit Management:
 Define credit profiles and limits.
 Periodic credit reviews ensure exposure is within safe boundaries.
 Approvals required for over-limit transactions.
5. AR Core Work Areas & Automation
Oracle Fusion AR provides the following main work areas:
 Billing Work Area: Enter and manage invoices, debit/credit memos, AutoInvoice, and customer
details.
 Receivables Balances Work Area: Review customer balances, receipts, and account status.
 Revenue Management: Manage revenue recognition and allocation (for complex
arrangements).
 Credit Management: Set and manage customer credit policies, reviews, and scores.
Automation Features:
 AutoInvoice: Automatically imports and validates bulk transactions from other systems (e.g.,
order management).
 AutoCash: Automatically applies receipts to invoices using configured rules (e.g., oldest first).
 Workflow Approvals: Transactions and credit limits exceeding thresholds trigger approvals.
6. Reporting & Inquiry
 Account Monitoring: Track aging, disputed items, unapplied cash, and overall collections
health from infolets and dashboards.
 Drill-Down Capabilities: Explore from account summary to transaction and payment detail.
 Notifications & Alerts: Remind collectors/AR clerks of pending activities (e.g., overdue
invoices, unapplied cash).
Diagram – Centralized Customer View
[Customer Summary]
↙ ↓ ↘
[Transactions][Receipts][Adjustments/Credit]
| | |
[Invoice][Deb Memo][Receipt]...

Summary Table: AR Core Concepts

Core Concept Key Details & System Support Example

Customers & Profiles, sites, and contacts; credit Global Tech, NY bill-to, $50K
Accounts policies limit

Transactions Invoices, memos, chargebacks, batch Invoice $10K, Credit Memo

entry $1K

Receipts Collection, allocation, automatic Receipt $10K for 2 invoices

application

Adjustments & Credits Write-offs, memos, approval limits Adjustment for pricing error

Credit Management Profiles, limits, reviews, approvals Periodic customer credit

scoring

Work Areas & Billing, Receivables, automation via Automated sales invoice
Automation AutoInvoice imports

Reporting & Inquiry Aged balances, dashboards, drill-downs Review overdue invoices
dashboard
In summary:
Oracle Fusion Cloud Receivables (AR) provides a comprehensive, centralized, and fully integrated
platform for managing customer accounts, processing invoices and payments, handling credits and
adjustments, and reporting—all with strong controls and automation, supporting efficient and
accurate receivables management aligned with your business needs.

Customers and Accounts

1. What Is a Customer?
A customer in Oracle Fusion Receivables is any person or business entity that receives goods or
services from your organization and may owe payment as a result.
 Each customer can have multiple accounts and sites, supporting complex business needs.

2. Customer Hierarchy and Components

a. Customer
 The top-level party (organization or person).
 Example: "Acme Corporation"
b. Customer Account
 Represents the financial relationship between your business and the customer, specific to one or
more business units.
 Stores crucial data: payment terms, currency, dun/billing settings.
 Example: Acme Corporation has an account with your "US Business Unit" for domestic
transactions and another for "EMEA Business Unit."
c. Customer Sites (Account Sites)
 Specific addresses and contact settings for the customer's business operations.
 Examples:
o Bill-to Site (where invoices sent): Acme, 123 Main St, New York, NY
o Ship-to Site (where goods are delivered): Acme Warehouse, 999 Logistics Park, NJ
o Statement Site (where statements or dunning letters go)
d. Contacts
 Individual persons related to specific accounts or sites (e.g., billing manager, AP clerk, ship-to
contact).
3. Customer and Account Setup Process – Stepwise Example
Scenario: Global Tech Ltd. becomes a new customer.
Ste Action Example Data
p

1 Create Party "Global Tech Ltd." (Company), tax registration, parent/child

relationships as needed

2 Create Account Account# GT1001 for "North America Business Unit", primary
currency: USD

3 Define Sites Bill-to: 1000 Fifth Ave, NY; Ship-to: 456 Mill Rd, Boston

4 Set Site Uses NY site as "Bill-to," Boston as "Ship-to"

5 Add Contacts Billing: jane.doe@globaltech.com; Shipping: mark.tan@globaltech.com

6 Set Account Payment terms: Net 30; Credit Limit: $50,000; Statement freq: monthly
Profile

4. Customer Relationships & Hierarchies

 Fusion supports parent-child hierarchies (e.g., "Acme Global" as parent, "Acme US" and
"Acme EU" as subsidiaries).
 Used for consolidated reporting, shared credit limits, or group dunning.
 Example Tree:
Acme Global (Parent)
├── Acme US (Subsidiary)
│ ├── Acme US - East Site
│ └── Acme US - West Site
└── Acme EU (Subsidiary)
└── Acme EU - Paris Site

5. Account Profile and Control

 Each customer account contains profile settings: credit limits, terms, statement cycles, risk
codes, and payment methods.
 Central to AR controls: can enforce order blocks if credit is exceeded, drive auto-cash
application, or trigger dunning.
 Example:
o "Net 45" payment term: invoices due in 45 days.
o $25,000 credit limit; if breached, new orders are flagged.
6. Usage in Transactions – Illustration
Invoice Transaction Example:
1. Select Customer: "Global Tech Ltd." (Account GT1001)
2. Choose "Bill-to" Site: 1000 Fifth Ave, NY
3. Enter Invoice: $5,000 for consulting (uses default payment terms from account profile)
4. Send Invoice: System uses bill-to contact and email set at site or account level.
Receipt Application:
1. Customer sends $5,000 payment.
2. Oracle Receivables matches payment to correct open invoices for Account GT1001, confirms
receipt, and updates outstanding balance.
7. Visual Diagrams
a. Customer Model Overview
graph TD
CUST[Customer: Global Tech Ltd.]
ACC[Account: GT1001]
S1[Bill-to Site: NY]
S2[Ship-to Site: Boston]
CON1[Jane Doe (Billing Contact)]
CON2[Mark Tan (Shipping Contact)]

CUST --> ACC

ACC --> S1
ACC --> S2
S1 --> CON1
S2 --> CON2

b. Customer-to-Transaction Flow
sequenceDiagram
Customer->>Receivables User: Supplies Purchase Order
Receivables User->>AR System: Creates Customer/Account/Site (if new)
AR System->>Receivables User: Provides Profile Defaults (payment terms, credit)
Receivables User->>AR System: Enters Invoice
AR System->>GL: Posts Receivable
Customer->>Receivables User: Sends Payment (Receipt)
Receivables User->>AR System: Applies Receipt, Closes Invoice

8. Centralized Data and Integration

 Customer data is shared across Receivables, Order Management, Collections, Advanced
Collections, and other Oracle Cloud modules.
 Changes to profiles, addresses, or contacts automatically flow to all relevant transactions—
ensuring accuracy and consistency.
9. Key Best Practices
 Define standard profile classes for consistent account setup.
 Use data quality management (duplicate prevention, address validation tools).
 Set up proper credit policies and review regularly.
 Map roles and controls for secure data changes (segregation of duties).
Summary:
Oracle Fusion Cloud Receivables lets you set up and manage customers and their accounts with
flexibility for complex business needs. Each customer can have multiple accounts, multiple sites, and
tailored contacts, all centrally maintained for billing, shipping, collections, and accurate reporting—
ensuring streamlined and compliant receivable operations across your enterprise.

Order-to-Cash (O2C) Overview in Oracle Fusion Cloud

The Order-to-Cash process encompasses the entire business flow from receiving a customer sales
order to collecting payment and posting revenue. In Oracle Fusion, this process tightly integrates
modules such as Order Management, Receivables (AR), and General Ledger for seamless processing.
1. High-Level Steps and Real-World Example
Ste Description Real-World Example
p

1 Order Entry Customer "Acme Corp" places an order for 20 laptops via Oracle Order
Management.

2 Order Fulfillment Warehouse ships the laptops. Delivery information is captured in Fusion
SCM.

3 Invoice Generation Upon shipment, Fusion AR automatically generates an invoice for Acme
Corp.

4 Invoice Delivery Invoice is emailed to Acme Corp’s billing contact and available on the
customer portal.

5 Receipts/Payment Acme Corp pays the invoice via bank transfer. Payment is entered or auto-
processed in AR.

6 Application & Payment is applied to the invoice (fully or partially), closing receivable, and
Reconciliation updating GL.

2. Detailed O2C Process Flow

A. Sales Order to Shipment
 Sales team/app user enters an order in Oracle Order Management, selecting the customer,
items/services, shipping address, and requested dates.
 System checks inventory and reserves stock.
 Upon fulfillment, warehouse confirms shipment in Fusion SCM.
B. Automatic Invoice Creation
 Once shipped, Fusion Cloud automatically generates a receivables invoice for the shipped
goods/services.
 Invoice includes details (customer, address, items, quantities, prices, due date, tax, etc.).
C. Invoice Review & Delivery
 AP clerk reviews the invoice in Receivables.
 Invoice is sent automatically to the customer as per preferences (email, print, portal).
D. Payment Receipt
 Customer remits payment via configured methods (wire, ACH, check).
 Payment may be processed manually or automatically (e.g., credit card authorization, lockbox
for check scanning).
E. Receipt Application
 In Oracle AR, user (or auto-cash rules) applies payment to relevant open invoices.
 Overpayments, underpayments, or unmatched amounts are flagged for follow-up.
F. GL Posting & Reconciliation
 Once payments are applied, accounting entries are posted to General Ledger.
 Reconciliation between posted AR receipts and bank statements is performed in Cash
Management.
 Revenue recognition is performed according to predefined policies or schedules.
3. Visual O2C Flow Diagrams
a. End-to-End Order-to-Cash Flow
flowchart TD
OE[Order Entry] --> OF[Fulfillment/Shipment]
OF --> IG[Invoice Generation]
IG --> ID[Invoice Delivery]
ID --> RP[Receipt/Payment]
RP --> RA[Receipt Application]
 RA --> GL[GL Posting & Reconciliation]

b. Example Sub-Flow – Invoicing and Receipts

sequenceDiagram
Customer->>Order Management: Places Order
Order Management->>Receivables: Triggers Invoice Generation
Receivables->>Customer: Sends Invoice
Customer->>Receivables: Sends Payment
Receivables->>GL: Posts Receivables Entry
Receivables->>Cash Management: Reconciles Payment

4. Key Features and Functional Controls

 Integration: Automatic flow from Order Management to Receivables; ensures accuracy and
speed.
 Validation: Invoices are validated against customer profiles (credit limit, terms) and business
rules.
 Automation: Payments can be applied automatically using autocash rules (oldest invoices first,
exact matches, etc.).
 Exception Handling: Disputes, short-payments, and unapplied receipts are tracked for follow-
up (e.g., create chargebacks or adjustments).
 Analytics: Dashboards show outstanding receivables, aging, collection history, and exceptions
for AR users and managers.
5. Practical Example – O2C in Action
1. Order Entry: "BlueView Software" enters a $50,000 order for services.
2. Fulfillment: Services completed, fulfillment marked in Fusion.
3. Invoice Generation & Delivery: System generates invoice INV-1001, emails to billing contact.
4. Payment: BlueView remits payment via wire transfer.
5. Receipt Application: $50,000 receipt recorded, automatically matched to INV-1001.
6. GL Posting: Receipt and revenue entries posted; AR aging report updated to reflect zero
balance for customer.
6. Best Practices Supported
 End-to-End Traceability: Each business event (order, invoice, payment) is tracked and
auditable.
 Flexible Configurations: Define different O2C processes for product, service, subscription
sales; set up customer credit controls, approval workflows, and payment automation.
 Seamless Integration: With inventory, fulfillment, AR, and financial reporting.
Summary:
The Order-to-Cash flow in Oracle Fusion Cloud Receivables provides a robust, standardized, and
integrated process that spans customer order capture through invoice generation and payment
collection, all the way to financial reconciliation—supported by automation, internal controls, and
real-time analytics for efficient AR operations and better customer management.

Receivables (AR) – Functional Mastery: Functional Flows: Invoice creation, adjustments,

receipt application, reversals
Here is an in-depth, official Oracle Fusion documentation-style explanation of Receivables (AR)
Functional Flows: Invoice Creation, Adjustments, Receipt Application, and Reversals in
Oracle Fusion Cloud Financials—with examples, diagrams, and illustrations for clarity.
1. Invoice Creation
Invoices represent amounts owed to your business for goods or services provided.
Methods of Invoice Creation:
 Manual Entry: Users enter invoice details directly in the Receivables work area.
 AutoInvoice Import: Bulk upload of invoices from order management, other systems, or
external sources using templates.
 Copy and Recurring Invoices: Users can copy previous invoices for recurring services or use
templates for subscription billing.
Key Fields:
 Customer, Account, Bill-to Site
  Invoice Date, Due Date, Currency
 Items/Services, Quantities, Unit Price
 Tax, Freight, Discounts
Example:
Acme Corp receives a $15,000 invoice for consulting services on July 1, due in 30 days (per customer
profile).
Invoice Creation Flow
flowchart TD
A[Start Invoice Creation] --> B[Enter Customer, Site]
B --> C[Add Line Items, Amounts, Tax]
C --> D[Validate & Save Invoice]
D --> E[Post to GL]

2. Adjustments
Adjustments modify the amount owed on existing invoices—e.g., due to errors, disputes, or
negotiated settlements.
Types:
 Credit Memo: Reduces the invoice amount (e.g., returned goods, overbilling).
 Debit Memo: Increases the amount due (e.g., late fees, additional services).
 Manual Adjustments: Small write-offs, price corrections, short payment resolution.
Approval Controls
 System enforces approval hierarchies for large or policy-sensitive adjustments.
 All actions are logged for audit.
Example:
Customer disputes $500 on a $15,000 invoice due to an extra item error. AR user creates a Credit
Memo, reducing balance to $14,500.
Adjustment Flow
graph TD
IV[Invoice Exists] --> CM[Create Adjustment (Credit/Debit Memo)]
CM --> AP[Approval (if needed)]
AP --> BAL[Update Invoice Balance]

3. Receipt Application
Receipt application allocates received payments (receipts) to open invoices. Receipts can be full or
partial and may involve multiple invoices per payment.
Steps:
 Enter Receipt: Record payment details (customer, amount, payment method, date).
 Apply to Invoices: Match receipt amounts to open invoices—using auto-application rules
(oldest first, exact match) or manual selection.
 Handle Variances: Address underpayments (short payments) with adjustments or
chargebacks, and manage overpayments as unapplied cash or on-account credits.
 Confirmation & Remittance: Confirms receipt is processed; if electronic, may await bank
confirmation.
Example:
Acme Corp sends a $14,500 payment covering two invoices ($10,000 and $4,500). Receipt is split
and fully applied; AR balance for those invoices becomes zero.
Receipt Application Flow
flowchart LR
R[Receipt Entry]
IV1[Invoice #1]
IV2[Invoice #2]
R --> A[Apply to Open Invoices]
A --> IV1
A --> IV2
IV1 & IV2 --> B[Update Invoice Status to Paid/Partially Paid]

4. Reversals
Reversals allow you to "undo" a receipt or adjustment that was applied in error, or to reverse an
incorrect allocation or payment.
Common Reversal Scenarios:
 Receipt Reversal: If a customer check bounces, a reversal removes the receipt application and
reopens invoices.
 Adjustment Reversal: If an adjustment was made by mistake, a reversal restores the original
invoice balance.
 Automatic and Manual Options: Receipts can be reversed individually or in bulk, with
mandatory reason codes for audit.
Example:
A receipt applied against Invoice #ON123 bounces due to insufficient funds. AR reverses the receipt,
invoice status reverts to "Open," and collections re-commence.
Reversal Flow
sequenceDiagram
AR User->>System: Select Applied Receipt/Adjustment
System->>AR User: Prompt for Reversal Reason, Confirmation
AR User->>System: Confirm Reversal
System->>Invoice: Unapplies Receipt/Adjustment, Reopens Invoice Balance
System->>Audit Log: Record Action and User

5. Visual Summary: End-to-End AR Flow

flowchart TD
IC[Invoice Creation] --> ADJ[Adjustment (if needed)]
IC --> RA[Receipt Application]
ADJ --> RA
RA --> RVS[Reversal (only if errors or exceptions)]
RVS --> RA

6. Key Controls & Best Practices

 Audit Trail: All entries, applications, and reversals are logged.
 Approvals: Defined by policy, with notifications for exceptions.
 Automation: Auto-cash rules and AutoInvoice reduce touchpoints.
 Reporting: Real-time dashboards for open balances, unapplied receipts, and adjustment
history.
In summary:
Oracle Fusion Cloud Receivables supports robust, auditable, and automated flows for invoice creation,
adjustments, receipt application, and reversals. Each action is controlled by user roles, workflow
approvals, and audit trails—ensuring error-free operations, compliance, and efficiency for AR teams,
as outlined in official Oracle documentation.

1. System Options in Receivables

Receivables System Options define foundational behaviors for the AR module at the business unit
level. These options impact invoice processing, receipt application, accounting, tax, and integration
with other modules.
A. Where to Configure
 From Setup and Maintenance, select:
Financials > Receivables > Manage Receivables System Options
B. Key Sections and Typical Settings
Section Example Settings Impact/Behavior

Accounting Default GL accounts for AR, revenue, tax Controls default posting of all AR
transactions

Customers Customer numbering, credit management, Sets how new customers and credit policies
statement cycles work

Invoices Default invoice types, payment terms, rounding Streamlines data entry and compliance for
rules transactions

Receipts Application rules (partial receipts, Dictates how receipts are auto-applied and
overpayment/write-off logic) allocated

AutoInvoice Import error handling, grouping rules, default tax Controls behavior of mass/batch invoice
info imports
 Tax Tax calculation/address options, reporting country Ensures compliance for multi-jurisdiction
invoicing

Approval/ Adjustment approval limits, user permissions, Imposes workflow control on sensitive AR
Adjustment write-off policies actions

Document Statement and transaction email settings, PDF Sets up how invoices/statements are sent to
Delivery templates customers

Illustration – Receivables System Options Screen:

graph LR
A[GL Accounts] -->|Defaults| I[Invoice Processing]
B[Customer Options] -->|Defaults| CI[Customer Creation/Update]
C[Invoice Rules] -->|Affects| IN[Transaction Entry]
D[Receipt Options] -->|Affects| RE[Receipt Application]
E[AutoInvoice] -->|Controls| AI[Mass Invoice Import]
F[Tax/Compliance] -->|Enforces| TC[Transaction Tax Rules]
G[Approval/Adj.] -->|Governs| AP[Approvals/Adjustments]

C. Example: System Option Settings for US Business Unit

Option Sample Value Description

Require Salesperson Yes Revenue accounting and sales credit

updates

Default Receivables 12100-US All invoices post to this account if not

Account overridden

Allow Partial Receipts Yes Payments can be applied partially

Header Level Rounding Enabled Round at transaction header for

compliance

Autoinvoice Grouping By Customer & Batches invoices by customer/date on

Rule Date import

Statement Cycle Monthly Statements sent monthly to all

customers

Adjustment Approval $10,000 per user Only higher roles can approve large
Limit write-offs

Diagram – System Options Impact Flow:

flowchart TD
SO[System Options]
IN[Invoice Entry]
RE[Receipt Processing]
AI[AutoInvoice]
AP[Adjustment Approval]
SO -- Sets defaults/controls --> IN
SO -- Sets allocation rules --> RE
SO -- Guides import/validation --> AI
SO -- Enforces limits/workflow --> AP

2. Transaction Options in Receivables

Transaction options govern how specific types of AR documents—like invoices, credit memos, debit
memos, and on-account credits—are created and processed.
A. Transaction Type Configuration
 Set up using:
Setup and Maintenance > Financials > Receivables > Manage Transaction Types
Attribute Examples/Explanation

Transaction Type Standard Invoice, Debit Memo, Credit Memo, Deposit,

Chargeback

Creation Method Manual, AutoInvoice Import, Recurring

 GL Account Source Sets which accounts are used for revenue, receivable, tax,
etc.

Default Payment “Net 30,” “Due on Receipt,” etc.

Terms

Approval/Flexfields Controls custom attributes, approval workflows, or

business rules

Document Keeps invoice/credit/debit doc numbers in sync for

Sequencing audit/compliance

B. Transaction Source Configuration

 Transaction Sources determine the origin and controls for imported or created AR documents:
o Auto-invoice, manual entry, or external integration
o Defaults for batch imports (e.g., ERP, eCommerce integration)
C. Example Table: Transaction Types
Name Class Natural Application Payment GL Account
Terms Source

AR Invoice Invoice Standard Net 30 Customer Profile

Credit Credit Reduces Receivable N/A Manual/Linked

Memo Memo Doc

Chargebac Adjustmen Increase AR, new Net 15 System

k t terms Generated

Deposit Deposit Applied to future N/A Customer Profile

invoices

Diagram – Transaction Type Influence Flow:

graph TD
TS[Transaction Type]
TE[Transaction Entry]
APP[Approval/Validation]
GL[GL Posting]
TS -- Sets required fields and flow --> TE
TE -- Dictates workflow --> APP
APP -- Uses source/type info --> GL

3. Putting It Together: End-to-End Example

Scenario:
 AR user creates a $5,000 invoice for "Global Tech Ltd." using a "Standard Invoice" transaction
type.
 System Option: Default receivables account is 12100-US, partial receipt is allowed, monthly
statements.
 Transaction Option: "Standard Invoice" uses Net 30 term, auto-numbering, posts to 12100-US if
not overridden by account rules.
Stepwise Flow:
1. User Enters Invoice: System auto-fills GL account, due date, and document number from
system and transaction options.
2. Validation: Rounding, salesperson, approval rules, and compliance policies are auto-enforced.
3. Invoice Sent: Email address and statement cycle defaults decide delivery.
4. Receipt Received Later: Payment can be partially applied (if for $3,000), system tracks
balance due.
5. Adjustment Needed: If user needs to write off $50 (as per underpayment), approval rules from
system options enforce review if over user’s limit.
4. Best Practices & Controls
 Centralized System Options: Ensure every AR business unit is set up with appropriate
defaults for compliance and efficiency.
 Transaction Options per Business Rule: Define transaction types and sources for every
business use-case (manual, import, recurring).
  Audit and Security: All changes in system or transaction options are logged, supporting strong
controls and compliance.
 Testing Custom Scenarios: Always test new options/configurations in a sandbox—
misconfigured options can impact all downstream AR processes.
Summary:
System options define foundational defaults and controls for Receivables; transaction options govern
how individual AR documents behave and are processed. Thoughtful configuration ensures accurate,
compliant, and efficient AR operations across transactions, customer management, and reporting—all
fully aligned to Oracle Fusion Cloud best practices and official documentation.

1. Receipt Classes
Definition:
A receipt class in Oracle Fusion Receivables determines the processing rules for receipts, specifying
how you receive, apply, and account for customer payments.
Configuration Components
Component Description

Receipt Method Type of payment (e.g., Check, Electronic, Wire, Credit Card)

Creation Method Manual or Automatic (e.g., AutoReceipts for recurring

payments)

Remittance Method Standard, Factoring, or None

Bank Account Defines which company bank account is used for this
Assignment receipt class

Clearance Controls Immediate (cleared on creation), or require manual/bank

confirmation

Example Table of Receipt Classes:

Receipt Receipt Creatio Remittan Clearance
Class Method n ce

Standard Check Manual Standard Remitted/

Manual Confirmed

Auto ACH/EFT Automat Direct/ Immediate

Electronic ic None

Credit Card Card Automat None Immediate

Processing ic

Configuration Flow
graph TD
RC[Create Receipt Class]
RM[Define Receipt Method]
REM[Set Remittance Method]
BA[Select Bank Account]
CL[Configure Clearance Policy]
RC --> RM --> REM --> BA --> CL

Practical Example:
 For auto-generated subscription payments (e.g., SaaS), configure a receipt class with:
o Method: Auto (ACH)
o Remittance: None (direct bank deposit)
o Clearance: Immediate
 For manual check receipts, configure:
o Method: Manual
o Remittance: Standard (bank deposit, wait for confirmation)
o Clearance: Requires bank reconciliation
2. Remittance and Remittance Methods
Definition:
Remittance is the process of delivering (remitting) customer receipts to the bank for deposit,
confirmation, or collection.
Remittance Method Types
 Standard Remittance:
Receipts are grouped into remittance batches and physically/electronically sent to the bank.
Status is updated upon confirmation (e.g., check deposits).
 Factoring Remittance:
Receivables are sold to a bank or third-party (factor), which then seeks collection from the
customer. Used for cash flow management.
 No Remittance:
Funds are received directly into your account, with no need for bank remittance processing (e.g.,
direct ACH payments).
Remittance Process Flow
flowchart LR
CR[Create Receipts] --> RB[Group into Remittance Batch]
RB --> SB[Send Batch to Bank]
SB --> CFM[Wait for Bank Confirmation]
CFM --> UPD[Update Receipt Status to 'Cleared']

Practical Example:
 Manual checks received from various customers are grouped into a remittance batch. The batch
is physically deposited at the bank. When cleared, Oracle Receivables marks those receipts as
‘Remitted’ then ‘Cleared’.
3. Customer Profiles
Definition:
Customer profiles are templates or settings applied to each customer account, controlling default
credit, payment, and collection behaviors.
Profile Attributes
Attribute Purpose Example Values

Payment Terms Default due date calculation Net 30, Due on

Receipt

Credit Limit Maximum outstanding receivables allowed $25,000

Statement Cycle How often statements are sent Monthly, Quarterly

Dunning Rules for overdue notices Level 1 after 10

Settings days

Receipt Auto-apply receipts, tolerance for short/over Apply oldest first

Application payments

Tax Attributes Determines tax codes, exemptions, and VAT Exempt, Standard
handling

Risk Used for credit reviews and risk assessment Low, Medium, High
Level/Scoring

Customer Profile Classes

 Used to group customers with similar credit/payment behaviors.
 Assigning a profile class sets default profile values for new customer accounts, reducing manual
entry.
Example: Business Customer Profile
Profile Attribute Value

Payment Terms Net 45

Credit Limit $50,000

 Statement Cycle Monthly

Dunning Escalate after 30

days

Default Receipt ACH

Method

Diagram: Customer Profile Usage

graph TD
PC[Profile Class] --> CA[Customer Account]
CA --> PI[Transaction Entry]
CA --> RE[Receipt Application]
CA --> DU[Dunning/Statements]
PC --> CA --> |Inherited Values| {Payment Terms, Credit, Risk}

Practical Example:
 All wholesale customers are assigned a profile class “Wholesale,” with $100,000 credit limit, Net
60 payment terms, and quarterly statement cycle.
 Retail customers get lower limits, Net 30, and monthly statements.
Summary Table: Configuration Interactions
Element Key Role in Receivables Typical Impact

Receipt Class Controls how receipts are Manual vs automatic, remittance,

handled clearance

Remittance Defines deposit/collection Impacts cash flow, receipt status

strategy

Customer Sets default account Terms, credit, risk, receipt

Profile behaviors application

In summary:
Oracle Fusion Cloud Receivables enables you to configure receipt classes for payment workflows,
remittance for banking processes, and customer profiles for tailored account behaviors. Each
configuration ensures streamlined, controlled, and auditable receivables management, aligning cash
application, risk, and customer service. All structures are interlinked and managed with robust
controls as outlined in Oracle’s official documentation for effective end-to-end AR operations.

Day 5: Cash Management (CM)

1. Core Concepts of Cash Management in Oracle Fusion Cloud

Oracle Fusion Cash Management provides centralized control over all aspects of bank account
management, bank statement processing, cash positioning, and reconciliation. Its main goals:
 Improve real-time cash visibility
 Automate and streamline reconciliation
 Support internal controls over cash movement
 Enable integration across Payables, Receivables, Payroll, and General Ledger
Key Features:
 Centralized management of internal and external bank accounts
 Electronic and manual bank statement processing
 Automated and manual reconciliation capabilities
 Cash position and cash forecasting tools
 Intercompany and internal transfers control
 Integration with reporting and analytics for cash and liquidity management

2. Bank Accounts: Setup and Management

a. Bank, Branch, and Account Structure
 Bank: The financial institution (e.g., CitiBank, HSBC).
 Bank Branch: Individual locations or codes within the bank, required for setup.
  Bank Account: The unique account entity used for transactions (disbursement, receipts,
settlement).
o Each account can be assigned to multiple business units—no need for duplication.
Setup Process (simplified flow):
flowchart LR
A[Create Bank] --> B[Create Branch]
B --> C[Create Bank Account]
C --> D[Assign Business Unit]

Example:
 Bank: "ABC Bank"
 Branch: "Delhi - 001"
 Account: "123456789" — used for all disbursements by the India business unit, enabled for both
payables and receivables.
Key Configuration Aspects:
 Define controls for each account: permitted transaction types, payment formats, and user
access.
 Assign each account appropriate usage: disbursement (Payables), remittance (Receivables),
payroll, etc.
 Set up approval hierarchies and audit requirements around bank accounts.
3. Bank Statements
Definition: Bank statements provide itemized details of all transactions (debits, credits, charges,
interest, etc.) that occurred in a bank account during a specific period.
Bank Statement Handling in Fusion Cloud:
 Electronic Bank Statement Processing:
o Supports industry formats: BAI2, SWIFT MT940, EDIFACT, ISO 20022, etc.
o Statements are imported automatically or manually as files (CSV, XML, TXT).
o Each statement includes opening and closing balances, all transactions, and relevant
codes.
 Manual Bank Statement Entry:
o Users can enter bank statement lines directly via a guided UI, typically for banks not
supporting electrified formats.
 Statement Structure
o Header (customer, period, opening/closing balance)
o Lines (transaction details: date, amount, payee/payer, type, reference)
Illustrative Flow – Bank Statement Processing:
flowchart TD
E[Electronic/Manual Statement Entry]
E --> V[Validation and Upload]
V --> S[Statement Lines Ready for Reconciliation]

4. Reconciliation Methods: Auto and Manual

Goal: Match transactions shown on the bank statement with those recorded in Oracle Payables,
Receivables, and General Ledger to ensure accuracy and detect discrepancies.
A. Automatic Reconciliation
How it works:
 System runs an Auto-Reconciliation process using matching rules assigned to each bank
account.
 Rules can match statement lines to system transactions based on multiple attributes (amount,
date, reference, type, etc.).
 Supports various matching types:
o One-to-One: Single statement line with single transaction
o One-to-Many/Many-to-One/Many-to-Many: Grouping statement lines or transactions for
complex reconciliations
 Configuration:
o Define matching rule sets (for sources like Payables, Receivables, Payroll, Journals,
External).
o Assign rule sets per bank account.
 o Set matching tolerances and criteria for unmatched items.
Process Flow – Auto-Reconciliation:
flowchart LR
A[Bank Statement Lines]
B[System Transactions]
A --Matching Rules--> R[Auto Match & Reconciliation]
B --Matching Rules--> R
R --> C[Cleared/Reconciled Items]
R --> U[Unmatched Items for Manual Review]

Example:
 Statement line: Outbound $10,000 to "ABC Supplies" on July 2
 System finds a matching Payables payment of $10,000—auto-matched and reconciled.
B. Manual Reconciliation
 Used for accounts with low transaction volume or handling exceptions not auto-matched.
 User reviews unreconciled statement lines/system transactions, and manually matches them
using UI tools.
 Manual reconciliation also supports handling “miscellaneous transactions” (e.g., bank fees,
interest) that may be created on the fly.
Process Flow – Manual Reconciliation:
flowchart LR
SU[Unmatched Statement Lines]
ST[Unmatched System Transactions]
SU --Manual Review/Selection--> MR[User Matches Lines]
ST --Manual Review/Selection--> MR
MR --> MC[Manually Cleared/Reconciled]

Example:
 A $150 bank fee appears on the statement, not recorded in Oracle; user manually creates a
miscellaneous transaction and reconciles it to the statement line.
5. Reporting & Integration
 Predefined Reports: Bank Statement Report (details and balances), Cash to General Ledger
Reconciliation Report (detects discrepancies), Cash In Transit, etc.
 Cash Positioning and Forecasting: Use reconciled bank data to monitor liquidity and forecast
future needs.
 Integration: Automatically posts reconciliation results to the General Ledger, ensuring real-time
cash balance accuracy.
6. End-to-End Cash Management Workflow Diagram
flowchart TD
BA[Bank/Account Setup]
BS[Bank Statement Import]
AR[Auto Reconciliation]
MR[Manual Reconciliation]
CF[Cash Forecasting/Positioning]
GL[GL Posting & Reporting]
BA --> BS
BS --> AR
AR --> MR
AR --> GL
MR --> GL
GL --> CF

Summary Table: Key Concepts

Concept Description Example/Scenario

Bank Logical setup for payments/receipts, tied to biz Disbursement account for AP
Account units

Bank Itemized list of all bank transactions for a period SWIFT MT940 electronic
Statement import

Auto Matches statement lines and system Payables payment matched to

Reconcile transactions via rules debit
 Manual User-driven matching and clearance Matching miscellaneous fee
Recon entry

Takeaways:
 Oracle Fusion Cloud Cash Management brings automated, secure, and auditable handling of all
cash and bank processes.
 It optimizes reconciliation—reducing manual effort—and provides complete transparency for
internal controls and audit.
 Powerful reporting and integration support enterprise-wide cash management and compliance.
These features are standard, robust, and align with all best practices and required controls detailed in
the official Oracle documentation.

1. Overview of Bank Statement Loading

Loading bank statements is the process by which external bank data is brought into Oracle Fusion
Cloud to reconcile bank transactions with system activity from Payables, Receivables, Payroll, and
General Ledger. This can be done electronically (recommended for most banks) or manually (for
banks not supporting electronic formats).
2. Types of Bank Statements
 Electronic Statements: Supplied by banks in standard industry formats, like BAI2, SWIFT
MT940, EDIFACT, or ISO 20022. Most modern banks provide these files daily, weekly, or monthly.
 Manual Statements: Keyed in by users if physical or PDF statements are received, or for
simple/one-off accounts.
3. Step-by-Step Process: Loading Bank Statements
A. Preparing to Load
a. Bank & Bank Account Setup
 Ensure the bank and relevant accounts are set up in Oracle Fusion CM and enabled for
statement loading.
 Assign formats/rules to these accounts (e.g., BAI2 for account “123456789” at HDFC Bank).
b. File Preparation
 Obtain the electronic statement file from your bank’s online portal. Example file:
ABC_BANK_20250730.bai2
 (Optional) Validate the file format—most banking portals provide download options compatible
with Oracle.
B. Loading Electronic Bank Statements
a. Navigation
 Go to: Cash Management > Bank Statements > Load Electronic Bank Statements
b. File Upload
 Select the bank account (e.g., “CITI-IND-1234”).
 Click “Upload File” and choose the statement file (e.g., CITI_JUL2025_MT940.txt).
 Set processing options:
o Import Only: Loads the data but does not run reconciliation.
o Import and Auto-Reconcile: Loads the data and immediately attempts to
match/reconcile transactions (recommended for routine operations).
c. Validation
 The system parses the file, checking structure and format (e.g., correct ISO 20022 syntax).
 If errors are detected, the system displays a log for review. Users correct errors and re-upload if
needed.
d. Review & Confirm
 After successful import, the bank statement appears in the list.
 Details such as opening and closing balances, statement date, and number of lines are shown.
 Drill down to see each transaction line (credits, debits, charges, interest, etc.).
C. Loading Manual Bank Statements
a. Navigation
 Go to: Cash Management > Bank Statements > Create Manual Bank Statement
b. Data Entry
  Enter statement header info: bank, account, statement number, dates, opening/closing
balances.
 Key in each line: transaction date, amount, type (e.g., payment, receipt, fee), references,
descriptions.
 Save and confirm.

Example: Manual Statement Entry Table

Date Amou Type Referen Description
nt ce

30-Jul- 10,000 Credit PAY1204 Receipt from

25 5 Acme

30-Jul- 5,000 Debit INV5432 Vendor Payment

25 1 XYZ

30-Jul- 100 Charg FEEJUL25 Monthly bank

25 e charge

4. Illustrative Flow Diagram

flowchart LR
F[Bank Provides Statement File] --> U[Upload in Oracle Cash Management]
U --Parse & Validate--> P[Process File]
P --No Errors--> L[Lines Loaded]
P --Errors--> ER[Error Review & Correction]
L --> R[Optional: Auto-Reconcile]
R --> C[Statement Ready for Review/Reconciliation]

5. Best Practices & Controls

 File Naming: Maintain standards for file names for traceability (e.g.,
BANKACCT_DATE_FORMAT.txt).
 Format Consistency: Coordinate with your bank to receive files in supported formats.
 Segregation of Duties: Restrict rights to upload/approve statements and perform
reconciliation for audit/security.
 Audit Trail: All imports, edits, and deletions are logged for compliance.
6. End-to-End Example Scenario
Scenario:
Your finance team receives a daily MT940 file HDFCBank_20250730.mt940 for account 456789123.
 The AP specialist logs into Oracle Fusion, navigates to Bank Statements, and uploads the file.
 The system parses 25 statement lines (12 debits, 10 credits, 3 charges).
 Two lines fail due to a date mismatch; user corrects and re-uploads.
 Upon successful load, the system launches auto-reconciliation, matching 22 lines to system
transactions.
 Unmatched lines are now flagged for manual reconciliation.
7. Visual Summary Table: Functional Flow
Step Action

File Acquisition Download/import bank statement (electronic/manual)

File Upload Select bank account and upload file in CM

File Processing Parse, validate, and store statement details/lines

Error Handling Review/upload corrections if errors occur

Review Check balances, lines, and prepare for reconciliation

Statement

(Optional) Auto- or manually match statement lines to system

Reconcile transactions

Summary:
Oracle Fusion Cloud makes loading bank statements streamlined and user-friendly, with robust
controls for both electronic and manual processes. Electronic loading is recommended for efficiency
and accuracy. Detailed dashboards, drill-downs, and error-handling tools ensure each statement is
correctly loaded, complete, and ready for automated or manual reconciliation—all as per standard,
documented Oracle Cloud procedures.

1. Overview: Purpose of Reconciliation

Reconciliation is the process of matching payments (to suppliers) and receipts (from customers)
recorded in Oracle Fusion with those shown on the organization's bank statements. This process
ensures:
 Banking records align with internal system transactions
 Errors or fraud are detected and resolved quickly
 Accurate cash position reporting and accounting
2. Reconciliation Types in Oracle Fusion CM
 Automated Reconciliation: The system automatically matches statement lines to internal
transactions based on user-defined matching rules.
 Manual Reconciliation: Used for exceptions, complex cases, or unmatched transactions. Users
perform matches using guided UIs.
3. Step-by-Step Reconciliation Process
A. Bank Statement Preparation
 Bank statements (electronic or manual) are loaded into Cash Management. Each statement
includes a list of debits, credits, and charges with details (date, amount, reference).
B. Payments and Receipts Import
 Payments created in Payables and receipts created in Receivables are automatically imported
into the CM module and marked as "Unreconciled".
C. Automatic Reconciliation: How It Works
1. Initiation
o User navigates to Cash Management > Bank Statements.
o Select the newly imported bank statement and trigger the "Auto-reconciliation" process.
2. Matching Rules
o The system uses configurable rules (amount, date, reference, payee/payer) to find matches
between bank statement lines and Oracle transactions.
o Matching types:
 One-to-One: E.g., a $5,000 bank debit matches a $5,000 AP payment.
 Many-to-One: E.g., multiple system receipts sum to a single bank deposit.
3. Clearing and Status Update
o Successfully matched payments/receipts are marked as "Cleared".
o Cleared transactions update cash balances in real time.
o Unmatched items are left as "Uncleared" for manual follow-up.
Illustrative Flow – Auto-Reconciliation
flowchart LR
ST[Bank Statement Lines]
IT[System Payments/Receipts]
ST --Matching Rules--> M[Auto-Match Process]
IT --Matching Rules--> M
M --> C[Cleared / Reconciled]
M --> U[Uncleared / Exceptions]

Example:
 Statement line: $10,000 credit labeled “Payment from Acme Corp”
 System finds a Receipt transaction for $10,000 from Acme Corp dated the same day
 Auto-reconciliation matches and marks both "cleared"
D. Manual Reconciliation: Exception Handling
1. User Review
o User examines uncleared statement lines and system transactions in the reconciliation UI.
2. Manual Matching
o For each unmatched item, the user:
 Reviews supporting details (reference numbers, descriptions).
 Selects system transactions that correspond to a statement line.
 Allows clearing of transactions that failed auto-matching due to discrepancies

(date variance, partial payments).
3. Miscellaneous Transactions
o For true bank-only items (fees, interest), users create miscellaneous transactions within
Cash Management and reconcile them to statement lines.
Example Manual Match Table:
Statement System Transaction Action
Line

$100 Bank None (not in system) Create Misc.

Fee

$3,000 Receipt from Global Manual

Credit Tech Match

$2,500 Debit Split across 2 AP Group &

payments Match

E. Reconciliation Completion and Reporting

 Once all possible matches are made, the statement status is updated to "Reconciled".
 Remaining unreconciled items are escalated for investigation.
 Reports are generated for audit and management review (e.g., Unreconciled Items Report, Cash-
to-GL Reconciliation).
4. Illustration: Functional Flow for Payment and Receipt Reconciliation
flowchart TD
BS[Bank Statement Loaded]
PT[Payments in Payables]
RT[Receipts in Receivables]
CM[Cash Management]
AR[Automatic Reconciliation]
MR[Manual Reconciliation]
CL[Update to GL / Reports]

BS --> AR
PT --> AR
RT --> AR
AR --> MR
AR --> CL
MR --> CL

5. Practical End-to-End Example

Scenario:
1. Your bank provides a daily MT940 statement file with 40 lines (20 credits, 18 debits, 2 fees).
2. You upload the file; CM imports and validates.
3. Auto-reconciliation matches 16 AP payments, 17 AR receipts, and 1 fee (configured as
recurring).
4. 6 lines left for manual match: split receipts, partial payments.
5. Manual reconciliation resolves 5 items; 1 is still uncleared (to be investigated).
6. All reconciled transactions are marked “cleared,” day’s cash report is produced for the
Treasurer.
6. Best Practices
 Use precise and consistent payment references to improve auto-matching.
 Set tolerances for small date or amount differences to maximize automation.
 Regularly review uncleared items and escalate as appropriate.
 Integrate reconciliation reports into the period-close checklist for audit readiness.
Summary Table: Reconciliation Actions
Task Automatic or Description
Manual

Auto-Reconcile Automatic Matches payments/receipts to bank lines using

rules
 Manual Manual User reviews and matches unmatched items
Reconcile

Misc. Manual Bank-only charges/entries created and cleared

Transactions in system

Reporting Both Cleared/unreconciled summary for audit and

review

In summary:
Oracle Fusion Cloud Cash Management enables accurate and efficient reconciliation of all payments
and receipts via automated or manual processes, providing complete real-time cash visibility, robust
audit controls, and streamlined financial operations—all fully in line with official Oracle Fusion
documentation and best practices.

1. Bank Account Creation for Payables (AP), Receivables (AR), and Cash
Management (CM)
A. Overview
In Oracle Fusion Cloud, bank accounts are created centrally and shared by various modules:
 Payables (AP): Used for outgoing payments to suppliers.
 Receivables (AR): Used to receive incoming payments from customers.
 Cash Management (CM): Used for bank reconciliation, cash analysis, and reporting.
Benefit: Centralization eliminates duplication, streamlines controls, and enables cross-functional
visibility.
B. Step-by-Step Bank Account Creation Process
Step 1: Access the Bank Account Management Screen
 Path: Setup and Maintenance > Financials > Cash Management > Manage Bank Accounts
Step 2: Create Bank and Branch (if new)
1. Enter Bank Name (e.g., “HDFC Bank”).
2. Add Bank Branch (“Delhi - Main Branch”), including branch codes and address.
Step 3: Define the Bank Account
1. Click “Create Bank Account” and fill out:
o Account Number (e.g., “00011223344”)
o Currency (e.g., INR, USD)
o Account Type (e.g., Checking, Savings)
o Description (e.g., “AP/AR Disbursement Account”)
2. Assign Bank and Branch (from steps above).
3. Select Account Owner (your legal entity or business unit).
4. Enter Opening Date, Status (active/inactive), and other basic fields.
Step 4: Assign Account Uses and Controls
 Enable the account for:
o Payables (Disbursement Account) for supplier payments.
o Receivables (Remittance Account) for customer receipts.
o Cash Management for reconciliation and forecasting.
 Assign the account to the relevant business units.
 Set required use contexts, such as AP, AR, Payroll, etc.
 For each use, specify payment methods/formats the account will support (e.g., checks for AP,
EFT for AR).
Step 5: Assign Security and Access Controls
 Define user/role access for managing, approving, and reconciling transactions.
 Audit trail is maintained for key actions (creation, edits, deactivation).
Step 6: Save and Validate
 Save the completed bank account.
 Test by attempting to select it in a Payables payment batch or Receivables remittance run.
Illustration: Bank Account Sharing Across Modules
graph TD
BA[Bank Account]
AP[Payables (AP)]
 AR[Receivables (AR)]
CM[Cash Management (CM)]
BA --> AP
BA --> AR
BA --> CM

This shows the central account being referenced by each finance module for their processes.
2. Cash Management Options
Cash Management Options configure how bank statements, reconciliation, and liquidity functions
operate for each business unit or legal entity.
A. Key Cash Management Options
Option Description

Bank Statement Import Specify accepted formats (BAI2, MT940), schedule for automatic
imports

Reconciliation Define auto-reconciliation rules, matching tolerances, and unmatched

Preferences item behavior

Bank Charges Handling Automate the creation of miscellaneous transactions for

charges/interest

Cash Forecasting Enable use of bank balances for cash position analysis
Controls

Access and Approval Assign approval chains for statement adjustments and reconciliation
Controls overrides

Allowed Transaction Restrict which modules can send transactions for a bank (e.g., AR only)
Sources

B. Functional Option Examples

1. Auto-Reconciliation Rule Example:
o Match by Amount, Date (±2 days), Reference Number.
o Auto-clear if within defined tolerance (e.g., ₹100).
2. Allowed Payment Methods & Documents:
o Check, EFT, Wire Transfer (set at the bank account level for each business unit).
3. Miscellaneous Transaction Setup:
o Map codes for accepted miscellaneous items (e.g., “Bank Fee”, “Interest Earned”).
C. Configuration Flow
flowchart TD
CMOPTS[Cash Management Options]
BA[Bank Account]
IMP[Import Bank Statements]
ARC[Auto-Reconciliation Config]
MISC[Misc. Transaction Handling]
REPORT[Cash Reporting/Forecast]

CMOPTS --> BA
CMOPTS --> IMP
CMOPTS --> ARC
CMOPTS --> MISC
CMOPTS --> REPORT

Cash Management Options shape how bank account data is processed, reconciled, and reported.
3. Practical Example: Disbursement Account for AP & Reconciliation Use
 "XYZ Pvt Ltd" opens Account 112233 at CitiBank, configured as follows:
o Assigned as Disbursement Account (AP): Used to pay suppliers.
o Enabled for Remittance (AR): Used to receive customer payments.
o Auto-Reconciliation Rule: 3-day match window, ₹200 tolerance.
 During month end, the bank statement is imported:
o Payments and receipts are auto-matched and reconciled in Oracle Cash Management.
 o Unmatched bank charges are created as miscellaneous transactions and reconciled
manually.
4. Best Practices
 Centralize account creation and control across business units for efficiency and compliance.
 Define clear use and reconciliation rules for each account, tailored to business needs.
 Use role-based security to segregate approval and reconciliation duties.
 Audit all changes and accesses to sensitive bank account data.
Summary:
Oracle Fusion Cloud enables robust, secure, and centralized configuration of bank accounts for AP,
AR, and CM purposes—all governed by flexible Cash Management Options. These elements work
together to streamline payments and receipts, automate reconciliation, and maintain tight controls
over enterprise cash operations—exactly as detailed in official Oracle documentation.

Day 6: Fixed Assets (FA)

1. FA Core Concepts
Oracle Fusion Fixed Assets (FA) manages the full lifecycle of tangible and intangible assets for
financial, tax, and reporting purposes. Its core goals are:
 Accurate tracking of assets' cost, location, and value
 Automated depreciation and compliance (statutory or management)
 Transparent adjustments, transfers, and retirements
2. Asset Categories
Definition:
Asset categories classify assets for accounting, reporting, and depreciation. Each category links to
accounting rules and default settings in an asset book.
Examples:
Asset Category Description Typical Assets

FURNITURE Office furniture Desks, chairs

COMPUTER_EQU Computer PCs, servers

IP equipment

LEASED_VEHICL Leased vehicles Company cars

ES

BUILDINGS Real estate Offices,

warehouses

Diagram: Asset Classification Structure

graph TD
ASSET[Asset]
CAT[Asset Category]
BOOK[Asset Book]
ASSET --> CAT
CAT --> BOOK

Assets are classified by category, which directs accounting and book selection.
3. Asset Books
Definition:
An asset book holds a collection of assets governed by a specific set of accounting, depreciation,
and reporting rules.
Types:
 Corporate Books: For standard (primary) accounting and reporting.
 Tax Books: For statutory/tax reporting as required (may run parallel to corporate).
Key Book Attributes:
 Currency, calendar (fiscal/tax year), depreciation rules, asset categories assigned.
Example:
 "US Corp Book": Used for US corporate reporting, USD currency, calendar year.
 "IN Tax Book": Used for Indian tax depreciation compliance, INR, April-March year.
4. Depreciation Methods
Defines how asset value is expensed over its useful life.
Common Methods:
Type Description Use Case

Straight Line Equal depreciation over asset life Buildings, intangibles

Declining Higher depreciation in early years IT equipment,

Balance vehicles

Units of Based on usage output (hours, qty) Manufacturing

Production machinery

Flat Rate Fixed percentage each year (per Certain tax books
statutory req.)

No Depreciation No expense recorded (land) Non-depreciating

assets

Diagram: Depreciation Calculation Example

flowchart TD
S[Asset Cost: $12,000]
L[Useful Life: 4 years]
M[Method: Straight Line]
S --> M
L --> M
M --> O[Annual Depreciation = $3,000]

5. Key Processes in Fixed Assets

A. Additions
Process: Brings new assets into the book.
Additions Sources:
 Manual entry
 Mass additions from Payables (invoices for capital items)
 Integrations (Project module, spreadsheets)
Example:
 AP team purchases a server ($5,000), tagged “COMPUTER_EQUIP”, added to "US Corp Book" for
5 years.
Addition Steps Flow:
flowchart LR
P[Purchase/Invoice]
V[Validation & Asset Category]
A[Addition to Asset Book]
P --> V --> A

B. Adjustments
Process: Update asset values or attributes after initial addition.
Types:
 Cost adjustment (e.g., asset improvement)
 Life adjustment (extending/reducing useful life)
 Category reassignment (move asset to new group)
Example:
Adding $1,000 in upgrades to an existing machine extends useful life by 2 years.
C. Transfers
Process: Move assets:
 Between locations (e.g., NY warehouse to LA office)
 Between cost centers or business units
 From one category/book to another
Transfer controls:
 Audit trail for all changes
 Automatic update of allocations and reporting
Diagram: Asset Transfer
sequenceDiagram
AP Specialist->>FA System: Select Asset
FA System->>User: Choose New Cost Center/Location
User->>FA System: Confirm Transfer
FA System->>GL: Update Accounting, Reporting

D. Retirements
Process: Remove assets from service (disposal, sale, write-off, loss)
Types:
 Sale/Disposal—asset sold, proceeds recorded, gain/loss calculated
 Write-Off—no proceeds, asset scrapped/lost
 Partial Retirement—only a component portion removed
Steps:
1. Select asset and initiate retirement.
2. Enter retirement type, date, and (if applicable) proceeds.
3. System calculates gain/loss and posts to GL.
4. Retired asset is recorded as inactive/historical.
Example:
 Sell a delivery van: original cost $10,000, accumulated depreciation $7,000, sale price $4,000.
System books gain/loss and closes asset.
6. End-to-End Lifecycle Diagram
flowchart LR
ADD[Addition]
ADJ[Adjustment]
TRA[Transfer]
DEP[Depreciation]
RET[Retirement/Disposal]
ADD --> ADJ
ADD --> TRA
ADD --> DEP
ADJ --> DEP
TRA --> DEP
DEP --> RET

Assets flow through addition, may be adjusted/transferred, depreciated over time, and finally retired.
7. Key Best Practices
 Design asset categories and books to align with accounting and reporting standards.
 Use automated integrations for mass asset additions and depreciation runs.
 Enforce user roles and audit controls for adjustments and retirements.
 Regularly review asset registers, run reconciliation between FA and GL.
Summary:
Oracle Fusion Cloud Fixed Assets provides end-to-end asset management—covering classification,
books, depreciation, and all key lifecycle events (additions, adjustments, transfers, retirements).
Robust controls, automation, and integrated analytics enable transparent financial reporting and
compliance—exactly as detailed in official Oracle documentation.
1. Overview: Asset Lifecycle in Oracle Fusion FA
The asset lifecycle in Oracle Fusion Cloud Fixed Assets spans from asset acquisition (addition)
through adjustments, transfers, depreciation, and finally retirement/disposal. Each stage is designed
for transparency, automation, and compliance.
2. Lifecycle Steps with Practical Examples and Diagrams
A. Asset Creation (Addition)
Assets can be added via:
 Manual Entry: Direct input (single asset).
 Mass Additions: Imported from Payables (capital expenditures), projects, or spreadsheets.
Example:
Your company buys a new $12,000 vehicle. AP pays the invoice, which is imported as a mass addition
in FA, assigned asset category “VEHICLES,” useful life 5 years, and added to the “US Corporate
Book.”
Addition Workflow:
flowchart LR
PP[Purchase or Invoice in AP/Projects]
QA[Qualify Asset/Import (Mass Additions)]
EN[Enter Asset Details (Category, Book, Cost, Life)]
VA[Validate/Complete Addition]
PP --> QA --> EN --> VA

B. Adjustments
Update asset properties after addition:
 Cost Adjustments: Added accessory (e.g., $2,000 GPS) increases asset value.
 Life Adjustments: Extend/reduce useful life based on real usage.
 Reclassification: Move asset from one category to another (e.g., Computer Equipment to
Servers).
Example:
A $1,000 engine upgrade increases vehicle cost and possibly its useful life.
C. Transfers
Moving assets within the organization:
 Between Locations: NY office to LA office.
 Between Departments: IT to Operations.
 Between Asset Books: For parallel accounting/tax records.
Transfer Process:
sequenceDiagram
User->>FA System: Select Asset for Transfer
FA System->>User: Enter New Department/Location Details
User->>FA System: Confirm Transfer
FA System->>GL: Update Asset Ownership/Accounting

D. Depreciation
Automatic periodic expense recognition of asset cost over useful life.
 Depreciation Run: Scheduled process calculates and posts monthly/periodic depreciation.
 Methods: Straight line, declining balance, units of production, etc.
 Book Assignment: Depreciation policies set per asset book.
Example Calculation:
 Vehicle cost: $13,000 (after upgrade), useful life: 5 years, straight-line.
 Annual depreciation: $2,600 ($13,000/5).
 Depreciation posted monthly or annually.
E. Asset Inquiry, Reporting, and Controls
 Asset Register: View details, cost, NBV (net book value), status, life-to-date depreciation.
 Audit Trail: Every addition, adjustment, transfer, and retirement is logged.
 Dashboards: Visualize asset statistics, status changes, and exceptions.
F. Retirement (Disposal/Write-Off/Sale)
Final removal of the asset from the active register.
Types of Retirement:
 Sale: Asset sold; proceeds booked; gain/loss calculated.
 Scrap/Write-Off: Disposed without proceeds (loss).
 Partial Retirement: Remove part of a composite asset.
Retirement Workflow:
flowchart TD
SA[Select Asset(s) for Retirement]
RT[Enter Retirement Details (Type, Date, Proceeds)]
CA[Calculate Gain/Loss]
UP[Update Asset Status & Post to GL]
SA --> RT --> CA --> UP

Example Scenarios:
 Sell vehicle for $5,000 after 4 years. FA system computes depreciation, current book value,
records cash proceeds, and posts gain/loss to GL.
 Write-off damaged laptop after 2 years without proceeds—system books loss on disposal, moves
asset to retired status.
3. End-to-End Lifecycle Flow in Oracle Fusion
flowchart LR
ADD[Asset Addition]
ADJ[Adjustment]
TRA[Transfer]
DEP[Depreciation]
RET[Retirement]
ADD --> ADJ
ADD --> TRA
ADD --> DEP
ADJ --> DEP
TRA --> DEP
DEP --> RET

4. Visual Example: Asset Register Snapshots

Asset Category Cost Dep In Service NBV Status
t

Dell IT_EQUIPMEN $8,000 IT 10-Jan- $5,20 Active

Server-1 T 2023 0

Ford Van-2 VEHICLES $13,00 Ops 02-Apr- $2,60 Retire

0 2022 0 d

Desk-14 FURNITURE $1,500 HR 15-Feb- $1,30 Active

2025 0

5. Best Practices:
 Use mass additions from AP/Projects for accuracy and efficiency.
 Schedule regular depreciation runs; automate postings to General Ledger.
 Use audit trails to track lifecycle events (compliance).
 Regularly review asset registers for active/retired status and reconcile with GL.
Summary:
Oracle Fusion Fixed Assets manages the full asset lifecycle—addition, adjustment, transfer,
depreciation, and retirement—with detailed controls, integration points (AP/GL), audit trails, and
visual tools. This ensures compliance, efficient tracking, and accurate financial reporting, exactly as
required for enterprise asset management.

1. Purpose of Mass Additions

Mass additions automate the transfer of capital asset costs from upstream modules (primarily
Payables and Projects) into Oracle Fusion Fixed Assets for standardized asset creation, classification,
and tracking. This streamlines high-volume processing, reduces manual errors, and ensures accurate
capitalization.
2. Mass Additions Sources
 Accounts Payable (AP): Invoices for capital purchases (e.g., computers, vehicles, equipment)
flagged as assets in AP flow into FA’s Mass Additions interface.
 Projects: Costs incurred on capital projects (e.g., building construction, infrastructure upgrades)
are accumulated and, once eligible, transferred as assets or asset components.
3. Step-by-Step Mass Additions Process
A. In Accounts Payable (AP)
1. Invoice Entry & Tagging
o AP user enters an invoice for an item intended as a fixed asset (e.g., "Dell Server" for
$8,000).
o Distribution line is coded to a capital expenditure account and flagged for asset tracking.
2. Invoice Validation & Approval
o Regular invoice validations occur, ensuring coding and amounts are correct.
3. Accounting and Transfer
o Once the invoice is accounted and paid (or as configured), entries flagged for asset
capitalization are extracted for mass addition.
B. In Oracle Projects
 1. Cost Accumulation
o Project expenditures (labor, materials) accumulate against a capital project (e.g., "HQ
Office Renovation").
2. Asset Assignment
o Project manager reviews incurred costs, designates which costs (or tasks) are asset-
eligible, and assigns asset categories.
3. Ready for Capitalization
o Upon reaching the right stage (project complete, or asset ready for use), costs are marked
as “ready for mass addition.”
C. In Fixed Assets (FA): Mass Additions Interface
1. Load Mass Additions
 AP and Projects extract eligible lines and populate the Mass Additions table in FA’s “Prepare
Mass Additions” work area.
2. Review and Prepare Assets
 Asset Accountant/FA User reviews the batched additions:
o Confirms/describes asset (e.g., “Dell Server SN: XYZ123”)
o Assigns correct asset book, category, location, cost center, depreciation method, and in-
service date
 Adjust or Combine: For grouped purchases (e.g., 10 laptops on one invoice), the user may
split or merge asset lines before finalizing.
3. Post Mass Additions
 Once reviewed, assets are “posted”—they move from the mass additions table to become
official assets in the asset register.
 The system creates corresponding accounting entries and schedules depreciation automatically.
4. Diagrams of Mass Additions Flow
A. Flowchart: AP to Fixed Assets
flowchart TD
AP[Invoice Entered in AP]
CEA[Capital Expenditure Account]
I[VOUCHER/INVOICE VALIDATION]
E[Extract to FA Mass Additions]
R[Review and Prepare Assets]
P[Post to Asset Register]

AP --> CEA --> I --> E --> R --> P

B. Project to Fixed Assets: Mass Addition Lifecycle

flowchart TD
PC[Project Costs Incurred]
AE[Asset Eligibility Review]
RA[Ready for Capitalization]
E[Extract to Mass Additions]
R[Prepare & Post in FA]
PC --> AE --> RA --> E --> R

5. Example: Mass Addition from AP

Scenario:
 Company receives an invoice for 15 workstations, $20,000 total, coded to capital account
“IT_EQUIPMENT.”
 AP pays invoice; the capital line is marked “Track as Asset.”
 During nightly batch, the line is transferred to FA Mass Additions.
 FA user reviews, splits into 15 asset lines, sets location as “NY Office,” asset book as “US Corp
Book.”
 Each asset is posted, starting depreciation from the “in-service” date.
6. Example: Mass Addition from Projects
Scenario:
 Project: "Solar Panel Installation" accumulates $180,000 in costs.
 At project completion, costs marked as asset-eligible; asset category set to “ENERGY_INFRA.”
 Mass Additions process in Projects pushes lines to FA.
  FA user creates one asset “Solar Field A,” useful life 20 years, assigns to Corporate Book.
 Asset is posted and depreciation scheduled to start FY begin date.
7. Key Controls and Best Practices
 Use proper coding and flags in AP and Projects to ensure valid assets are captured.
 Leverage batch reviews to adjust incorrect data and allocate assets properly before posting.
 Automate recurring mass additions for high-volume enterprises (integration with AP and Project
modules).
 Maintain clear audit trail: Source invoice/project is always traceable from the asset record.
Summary Table: Mass Additions Flow
Source Trigger Prepped in FA Final Outcome

AP Capital Distribution Prepare Mass Posted Asset, Scheduled

Invoice Line Additions Depreciation

Projects Asset-Eligible Project Prepare Mass Posted Asset(s), Scheduled

Costs Additions Depreciation

Summary:
Mass additions from AP and Projects in Oracle Fusion Cloud Financials ensure fast, accurate, and
compliant asset creation and capitalization. Automated extraction, user validation, and seamless
posting integrate operational purchases and projects with fixed asset accounting, supporting robust
lifecycle management and financial visibility.

Fixed Assets (FA): Configuration: Asset key flexfields, depreciation methods, asset books
setup

1. Asset Key Flexfields (AKF)

Definition:
Asset key flexfields in Oracle Fusion FA are multi-segment fields allowing organizations to track and
classify assets using attributes tailored to business needs—beyond mere category or tag. Flexfields
enable robust reporting, grouping, and validation.
A. Configuration and Segments
 Segments: Each flexfield can have multiple predefined or custom segments such as Asset
Type, Location, Department, Project, Serial Number, etc.
 Setup Example:
o Segment 1: Location (e.g., "NYC Office", "Plant-1")
o Segment 2: Asset Type (e.g., "Hardware", "Vehicle", "Furniture")
o Segment 3: Department (e.g., "Finance", "HR", "IT")
Diagram: Asset Key Flexfield Structure
graph TD
AKF[Asset Key Flexfield]
SEG1(Location)
SEG2(Asset Type)
SEG3(Department)
AKF --> SEG1
AKF --> SEG2
AKF --> SEG3

B. Flexfield Usage and Best Practices

 Value Sets: List allowed codes/values for each segment to standardize data entry (e.g., only
valid location codes).
 Assignment: Flexfields are defined during asset addition, ensuring traceability and facilitating
search/reporting.
 Validation Rules: Ensure correct segment combinations, enforcing business controls.
Example:
A workstation asset could have:
 Location: NYC
 Asset Type: Hardware
 Department: IT
Resulting key: NYC-HARDWARE-IT
2. Depreciation Methods
Definition:
Defines how the value of an asset is expensed over its useful life. Each book can support multiple
methods and assign them at the category or asset level.
A. Depreciation Method Types
Method Description Example Use Case

Straight Line Equal depreciation each year Office buildings, intangibles

Declining Balance Higher depreciation in early years, lower in Machinery, vehicles

later years

Sum-of-the-Years’ Acceleration method, higher charges up front Specialized plant equipment

Digits

Units of Production Depreciation based on usage/units produced Printing presses, vehicles

(not time)

Flat Rate Fixed percentage charge per year Certain assets for statutory
reporting

No Depreciation Assets like land Land, artwork

Straight Line Example Calculation:

 Cost: $12,000
 Useful Life: 4 years
 Annual Depreciation = $3,000/year
Diagram: Depreciation Trend
graph LR
SL(Straight Line)
DB(Declining Balance)
X[Years]
Y[Expense]

SL --Flat Depreciation--> X
DB --High-to-Low Depreciation--> X

B. Configuring Depreciation Methods

 Define method attributes for each book (calculation formula, convention, limits).
 Assign defaults by asset category or set per individual asset.
3. Asset Books Setup
Definition:
An asset book is a set of rules and controls for managing groups of assets, their accounting, and
compliance.
A. Types of Books
 Corporate Books: For standard accounting/reporting as per company policy.
 Tax Books: For compliant depreciation under local statutory tax laws.
 Budget Books: Optional, for planning or simulation studies.
B. Key Setup Components
Book Attribute Description

Calendar Fiscal/calendar year periods

Currency Base currency for asset values

Depreciation Rules Allows choice of allowed methods, default

values

Asset Categories Which categories/assets are managed in

Assigned this book

Accounting Rules Accounts for asset cost, depreciation,

gain/loss
C. Asset Book Setup Flow
flowchart TD
NB[New Asset Book Setup]
CAL[Set Calendar/Periods]
CUR[Set Currency]
DM[Define Depreciation Methods]
AC[Assign Categories]
AR[Configure Accounting Rules]

NB --> CAL --> CUR --> DM --> AC --> AR

D. Example: Corporate and Tax Book Setup

 Corporate Book ("US Corporate Book")
o Currency: USD
o Calendar: Jan-Dec
o Depreciation: Straight Line (default), DB (alternate)
o Asset Categories: Office Equipment, Vehicles, Buildings
 Tax Book ("US Federal Tax Book")
o Currency: USD
o Calendar: Jan-Dec
o Depreciation: MACRS (Accelerated per IRS)
o Asset Categories: All corporate book assets mirrored
4. Visual Summary Table
Configuration Area Key Elements Example Purpose

Asset Key Segments, value sets, business logic Track asset by location &
Flexfields department

Depreciation Straight line, declining balance, custom Control how cost is expensed
Methods formulas

Asset Books Calendar, currency, depreciation, Set statutory vs. Mgmt

categories reporting

Summary:
In Oracle Fusion Cloud FA, robust configuration of asset key flexfields, depreciation methods, and
asset books enables precise tracking, compliant accounting, and flexible reporting for any asset
portfolio. Proper setup supports automation, auditability, and tailored lifecycle management—all
essential for enterprise asset management as described in official documentation.

Integration & End-to-End Implementation Flows: Data flow across GL, AP, AR, CM, FA
1. Overview: Integrated Financials in Oracle Fusion Cloud
Oracle Fusion Cloud Financials is designed for seamless integration across modules, ensuring end-to-
end visibility, robust controls, and automation. Every subsystem (AP, AR, FA, CM) interacts with
General Ledger (GL) as the accounting backbone—but each also exchanges data with the others for
transaction, payment, and reconciliation purposes.
2. High-Level End-to-End Data Flow
Example of an Integrated Process
 AP (Payables): Supplier invoice is entered and paid.
o Generates accounting, impacts cash balances.
o Feeds payment transactions to CM (for bank reconciliation).
o Capital asset invoice lines flow to FA via mass additions.
 AR (Receivables): Customer invoice is created, payment received.
o Payment receipts update bank accounts in CM and post to GL.
o Customer assets (e.g., leased equipment) can be tracked in FA.
 FA (Fixed Assets): Capital items purchased via AP are capitalized in FA.
o Depreciation entries post to GL.
o Asset disposals may generate AR transactions (e.g., sale proceeds).
 CM (Cash Management): Bank accounts reflect payments and receipts from AP/AR.
 o Reconciles these to actual bank statements.
o Updates cash position, triggers GL postings.
 GL (General Ledger): Receives all accounting entries.
o Consolidates/payments, receipts, asset transactions, reconciliations for financial reporting.
3. Detailed Integration Points with Examples
A. Payables (AP) to GL and CM
 Supplier Invoices entered in AP are validated and approved.
 Accounting entries for expense/liability are posted to GL.
 Payments made to suppliers:
o Reduce liability in GL.
o Create payment transactions that flow to CM for bank reconciliation.
 Mass Additions: AP invoices for fixed assets are sent to FA for asset creation and depreciation
setup.
Illustration: AP Integration Flow
flowchart LR
AP[AP Invoice Entry]
GL[GL Posting]
CM[Cash Management]
FA[Fixed Assets]
AP --Accounting Entries--> GL
AP --Payments--> CM
AP --Asset Lines--> FA
FA --Depreciation/Retirement--> GL

B. Receivables (AR) to GL and CM

 Customer Invoices are created in AR.
o Revenue and AR entries post to GL.
 Receipts (payments from customers):
o Update AR, reduce outstanding receivables.
o Update GL (cash, clearing accounts).
o Reflect cash inflows in CM for bank account reconciliation.
Example:
Payment from "Acme Corp" is received and recorded in AR, appears in CM for matching with the bank
statement, and posts cash entries in the GL.
C. Fixed Assets (FA) Integration
 Additions: Asset purchases from AP are imported as "mass additions."
 Depreciation: Monthly/periodic depreciation runs in FA generate journal entries posted to GL.
 Asset Transfers/Retirements: FA posts gain/loss on disposals to GL; asset sales may result in
AR invoices.
Diagram: Asset Data Flow
flowchart LR
AP[Capital Invoice in AP] --> FA[Mass Addition in FA]
FA --> GL[Depreciation, Retirement Journals]
FA --Sale--> AR[Customer Invoice]

D. Cash Management (CM) Integration

 Bank accounts are centrally managed and shared across AP, AR, and Payroll.
 Bank Statements are imported into CM.
o Payments (from AP), receipts (from AR), and miscellaneous items are auto-matched to bank
statement lines.
o Reconciled/corrected status posts adjustments to GL.
 Cash Positioning: Outputs current balances for treasury, updates GL cash accounts.
CM Integration Flow Example
flowchart TD
AP_Pay[AP Payments] --> CM
AR_Rec[AR Receipts] --> CM
CM --Reconciliation--> GL
CM --Bank Charges/Interest--> GL
E. General Ledger (GL): The Accounting Hub
 Aggregates all subledger transactions using Subledger Accounting (SLA).
 Each module posts summarized/detailed accounting per configuration.
 GL journal entries: For payments, receipts, asset depreciation, bank reconciliations.
 Reconciliations: Drill-back from GL balances to originating AP/AR/FA/CM transactions for full
audit trail.
Integrated Flow Diagram
flowchart LR
AP[Payables]
AR[Receivables]
FA[Fixed Assets]
CM[Cash Management]
GL[General Ledger]
AP --> GL
AR --> GL
FA --> GL
CM --> GL
AP --> CM
AR --> CM
AP --> FA
FA --> AR

4. End-to-End Scenario: Data Movement

Scenario:
Company purchases equipment (AP invoice coded as asset), pays supplier (AP payment). The asset is
added to FA and begins depreciation. A customer buys old equipment (FA triggers AR invoice). All
cash flows are reflected and reconciled in CM. All transactions post summarized entries in GL.
 Data is entered once and flows seamlessly from transaction origin to ultimate reporting,
with validation and audit at each staging point.
5. Key Takeaways
 Single Source of Truth: Centralized master data (suppliers, customers, bank accounts)
ensures data entered anywhere is reusable everywhere.
 Automated Flows: Mass additions, payment/receipt interfaces, and reconciliation automate
transaction flow between modules.
 Real-Time Analytics: Integrated dashboards reflect data movement and balances immediately
across all related modules.
 Auditability: Drill-downs from GL to subledger source, with traceability across the entire
lifecycle.
Summary Table: Cross-Module Data Flow
From To What Flows Example
Module Module

AP GL Accruals, payments Supplier invoice posts to liability acct.

AR GL Revenue, cash Sales invoice and payment posting

receipts

AP FA Asset additions Capital goods invoice triggers asset addition

FA GL Depreciation, Monthly depreciation, disposal gains/losses

retirements

FA AR Asset sales Sale of retired asset produces AR invoice

AP/AR CM Payments/Receipts AP payments and AR receipts available for

reconciliation

CM GL Cleared cash, bank Bank statement adjustments post to GL

charges

In conclusion:
Oracle Fusion Cloud Financials delivers deeply integrated, end-to-end data flows between GL, AP, AR,
CM, and FA—enabling automated, auditable, and efficient financial operations from transaction
initiation through final reporting. Each module plays its part in the enterprise-wide financial picture
and is tightly linked for data integrity, compliance, and control, exactly as per Oracle’s official
documentation.

Integration & End-to-End Implementation Flows: Key dependencies (e.g., Subledger

Accounting flows, reconciliations)

1. Subledger Accounting (SLA) Flows: Foundation of Data Integration

Subledger Accounting (SLA) is a powerful Oracle Fusion framework that sits between the
operational subledgers (AP, AR, FA, CM, etc.) and the General Ledger (GL). It standardizes and
controls how business events generate accounting entries, ensuring full compliance and auditability.
How SLA Works
A. Business Event Occurs in Subledger
 Example: A supplier invoice is validated in Payables (AP), or a customer payment is received in
Receivables (AR).
B. SLA Generates Accounting Entries
 Each business event (invoice, receipt, asset addition) triggers configured SLA rules.
 SLA determines accounts, debit/credit, and detailed justification per event.
C. Account Derivation and Transformation
 SLA uses account derivation rules to map operational data (e.g., supplier site, business unit,
asset category) to correct GL accounts.
 Rules can be tailored to organizational, statutory, or management needs.
D. Posting and Drill-Back
 Draft Accounting: Users can preview and validate accounting before posting.
 Final Posting: Approved entries are transferred/posted to GL.
 Drill-back: Users can drill from GL to subledger source transactions via linked references.
Visual Illustration: Subledger to GL Flow
flowchart TD
AP[AP/AR/FA/CM Subledger Event]
SLA[SLA: Derive & Create Accounting Entries]
GL[General Ledger Posting]
AP --> SLA --> GL
GL --Drill-Back--> SLA --> AP

Example:
 An AP invoice for $10,000 results in specific accounting entries (debit expense, credit liability) as
per SLA setup.
 Custom rules may impact how costs, taxes, or currency gains/losses are mapped.
2. Reconciliations: Critical Integration Dependencies
Reconciliation is essential to verify that balances and movements across modules remain consistent
and traceable—no duplication, loss, or misstatement.
A. Subledger to GL Reconciliation
 Purpose: Ensure all (AP, AR, FA) accounted transactions are accurately and fully posted into the
GL.
 Process:
o Transfer to GL: Subledger-batch or real-time transfers via SLA.
o GL Reconciliation Reports: Compare subledger closing balances/journal lines with
corresponding GL account balances.
o Exception Handling: Untransferred, errored, or pending transactions are flagged for
review.
Diagram: Reconciliation Overview
flowchart LR
SL[Subledger Closing Balance]
SLA[SLA Entries]
GLB[GL Account Balance]
SL --Compare--> GLB
SLA --Investigate Errors--> GLB

Example:
  The AP subledger’s liability balance for June is $500,000. The GL’s AP liability account must show
$500,000 for the same period. Any difference triggers a subledger-to-GL reconciliation report.
B. Bank Reconciliation Across AP/AR/CM
 Cash Management reconciles both AP outgoing payments and AR incoming receipts to actual
bank statement lines.
 Dependencies:
o AP payments must be fully processed and marked as “cleared” only when matched in CM.
o AR receipts not showing in the bank statement are logged as exceptions for manual follow-
up.
 Automation: Oracle supports automatic reconciliation using rules (amount, date, reference),
flagging exceptions for resolution.
Illustration: End-to-End Cash Reconciliation
flowchart LR
AP_P[AP Payment]
AR_R[AR Receipt]
CM[Bank Statement in CM]
REC[Reconciliation Process]
AP_P & AR_R --> REC --> CM
REC --> [Cleared/Uncleared Status]

C. FA-GL Asset Reconciliation

 FA runs (additions, transfers, retirements, monthly depreciation) automatically generate SLA
accounting that is posted to GL.
 FA-GL Control Reports ensure asset and accumulated depreciation balances in FA equal
relevant fixed asset and depreciation accounts in GL.
3. Key Implementation Dependencies
Dependency Description Why It Matters

SLA Setup & Rules Proper mapping ensures right accounts, alignment with policies; Inaccurate rules = wrong
impacts all subledger flows GL data

Period Status GL and subledgers must have matching period statuses to Prevents missed/late
Synchronization ensure transactions flow end-to-end and closing steps are postings, closing errors
sequenced

Reference Data Reference data sets for payment terms, account structures, etc. Avoids mismatched setups
Sharing must be shared across modules for consistency and data silos

Reconciliation Controls Automated and manual reconciliation must be scheduled, Prevents misstatements,
& Reporting reviewed, and acted upon enables audit trail

Drill-Down Setup Proper linkage for drill-downs from GL to subledger (source Enables transparency,
system reference, unique IDs, etc.) auditability

4. Example: End-to-End Flow with Dependencies

Scenario:
 An AP invoice for a capital item is entered.
o SLA rules create expense and liability entries (AP).
o When paid, the payment is recorded and sent to Cash Management (dependency on open
periods).
o Payment is matched to the bank statement during reconciliation (dependency on correct
matching rules/data).
o If invoice is for an asset, a mass addition is triggered, leading to asset creation in FA; SLA
in FA posts depreciation monthly to GL.
o Throughout, all reference data (accounts, periods, categories) must be consistent and
properly linked.
5. Best Practices for Implementation
 Design SLA rules first, involving GL, AP, AR, FA, and CM teams for full buy-in and end-to-end
mapping.
 Test period-close and reconciliation cycles in pre-production with real data scenarios.
  Implement exception dashboards for transfers to GL and reconciliation failures for timely
intervention.
 Use "drill-back" configuration to support GL to subledger audits and transparency.
Summary Table: Key Dependencies and Risk Controls
Integration Area Key Dependency Control/Monitoring Approach

SLA Rules align with business/account Review/test rules, validate sample

policies events

Subledger to GL Complete, error-free transfer Daily reconciliation & error log

reviews

Bank Payments tie to system Setup rules, regularly review

Reconciliation transactions exceptions

Asset FA and GL reconciled monthly Compare asset/depreciation

Accounting balances

Reference Data Synchronized config across Use reference data sets, regular
modules reviews

In conclusion:
Key dependencies like SLA configuration, reference data sharing, period management, and robust
reconciliation are foundational to Oracle Fusion Cloud Financials’ integration. They ensure error-free
data and process flow across GL, AP, AR, CM, and FA—enabling compliance, transparency, and
efficiency.
All diagrams above depict standard Oracle-documented flows for end-to-end implementation success.

Common Implementation Tasks: Rapid implementation spreadsheets, Data migration

strategies (opening balances, supplier/customer import), Troubleshooting and functional
diagnostics
1. Rapid Implementation Spreadsheets
Purpose:
Rapid implementation spreadsheets accelerate the setup of foundational data (such as Chart of
Accounts, Ledgers, Business Units, Suppliers, Customers) by allowing users to define and upload large
data sets via pre-formatted Excel templates.
A. How Rapid Implementation Works
 Oracle provides downloadable Excel templates for each key area (e.g., Chart of Accounts, Legal
Entities, Suppliers).
 Users fill in required structure/data offline.
 Spreadsheets are validated (for logic, duplicates, required fields) before import.
 Oracle’s “Upload” feature parses the file and creates records in the application.
Stepwise Example: Setting Up Chart of Accounts Using Spreadsheet
1. Download the "Chart of Accounts" implementation template from FSM or Setup area.
2. Populate segments, value sets, and hierarchies in Excel.
3. Upload & Validate the file via Setup and Maintenance –> Rapid Implementation.
4. System Feedback displays any errors; correct and re-upload if required.
5. On Success, Oracle builds all structures: accounts, segment labels, hierarchies.
flowchart LR
DL[Download Template] --> ED[Edit in Excel]
ED --> UL[Upload Spreadsheet]
UL --> VD[Validate Data]
VD --Errors?--> ED
VD --No Errors--> CM[Create Config in Oracle]

Other Use Cases:

 Supplier/Customer upload
 Ledger and Business Unit setup
 Bank accounts, payment methods import
Benefits:
 Mass upload reduces manual setup time.
 Consistent and validated data structure.
2. Data Migration Strategies
Data migration is crucial for go-live success—bringing essential data (opening balances, master data)
from legacy or external systems into Oracle Fusion Cloud.
A. Typical Migration Areas
a. Opening Balances (GL, Subledgers):
 Import trial balances from legacy systems to ensure GL starts aligned.
 Use specific FBDI (File-Based Data Import) templates for “Journal Import.”
Example: Opening GL Balances Migration
1. Extract closing TB from legacy system, format per Oracle’s “Journal Import” template.
2. Complete header (ledger, period, category), then line info (accounts, amounts).
3. Upload via FSM upload/import process.
4. Review logs for errors, fix, and rerun as needed.
5. Post imported journals in Oracle GL.
graph TD
LS[Legacy TB extract]
TMP[Template Fill-Out]
UP[Upload to Oracle]
VL[Validate/Correct]
PST[Post in GL]
LS --> TMP --> UP --> VL --> PST

b. Supplier/Customer Import
 Use Oracle-supplied FBDI templates for Suppliers (AP) and Customers (AR).
 Map legacy data fields (names, sites, contacts, tax, payment terms) to Oracle’s template
columns.
 Validate and upload; system creates master records and any hierarchies (parent/child links).
Example Table: Supplier FBDI Mapping
Legacy System FBDI Column Example
Field Value

Vendor Name Supplier Name Acme Corp

Address Line 1 Supplier Address 123 Main

Line 1 Street

Country Code Country USA

Payment Terms Payment Terms Net 30

Tax Registration Taxpayer ID AB123456C

B. Migration Best Practices

 Cleanse data (remove duplicates, standardize formats) before migration.
 Use test environments to validate uploads and reconciliation.
 Immobilize or restrict data entry during “cutover” to avoid mismatch.
 Always migrate reference/master data before transactional data to prevent dependency errors.
3. Troubleshooting and Functional Diagnostics
Oracle Fusion provides robust tools and processes for identifying, researching, and correcting issues
during implementation or live operation.
A. Common Diagnostic Tools & Methods
a. Transaction Error Handling
 Error Messages & Logs: Most import/process errors show detailed messages (e.g., missing
required field, invalid value).
 Transaction Reports: Diagnostic reports (like “Journal Import Errors,” “Supplier Import Log”)
pinpoint failed records.
b. Diagnostic Dashboards
 Work areas include “Exceptions” or “Diagnostics” tabs (e.g., AP Invoice Holds tab lists all held
invoices).
 GL, AP, AR, FA, and CM each provide dashboards for unresolved items, approvals, or
configuration errors.
c. Setup Validation Tools
  Functional Setup Manager (FSM): Warnings appear for missing dependencies or incomplete
setups.
 Diagnostic Tests: FSM “Test” features for ledgers, accounting calendars, and cross-module
dependencies.
d. Inquiry and Audit
 Drill-Down: Always drill from error balances or suspense accounts in GL to source transactions.
 Audit Trails: Review change logs for master data, setups, or transactional edits.
B. Troubleshooting and Diagnostics Example
Scenario: Supplier Import Fails
1. Upload logs show error “Invalid Payment Method.”
2. User reviews error log, finds payment method code is not predefined in Oracle.
3. Add missing payment method via setup; correct template data.
4. Re-upload file, now successful.
Diagnostic Flow:
sequenceDiagram
User->>Oracle: Bulk Data Import
Oracle->>User: Error Log Output
User->>User: Check Error Explanation
User->>Oracle: Correct Setup / Data
Oracle->>User: Repeat Import --> Success

C. Key Best Practices

 Use system-supplied error messages as guides for quick root cause analysis.
 Always fix setup or configuration errors before re-attempting data imports.
 For persistent issues, leverage Oracle’s Support diagnostics and knowledge base tools packaged
in Cloud Help and My Oracle Support.
Summary Table: Implementation Task Areas
Task Tool/Approach Example/Visual

Rapid Implementation Excel Templates + Upload CoA, Ledgers, Suppliers import

Data Migration FBDI Templates, Import, Test Opening balances,

Supplier/Customer load

Troubleshooting/ Error Logs, Dashboards, Drill-Down, Invoice Hold dashboard, Error log
Diagnostics Audit review

In conclusion:
Oracle Fusion Cloud Financials supports rapid, efficient implementation through spreadsheet-driven
setup, robust data migration frameworks, and layered diagnostic tools—ensuring functional
consultants can configure, load data, and validate processes reliably and transparently, all in strict
alignment with official Oracle documentation and best practices.