Oracle Invoice Accounting Testing

It is the process by which a validated invoice becomes a journal in the ledger. Validation raises an accounting event, Subledger Accounting applies its rules to derive each account, and Create Accounting generates a balanced subledger journal of debits and credits that is then transferred to the General Ledger and posted.

Distribution testing owns the accounting inputs — the account combinations, allocations, project and asset attributes, and distribution balancing on the invoice. This page owns what Subledger Accounting does with those inputs: the accounting events, SLA journals, account derivation, transfer, posting, and reconciliation. See the distribution testing page for the inputs.

The general Subledger Accounting Testing page covers the SLA engine across all subledgers — accounting methods, journal-line rules, and mapping sets. This page is the Payables-invoice-specific view of that engine: the accounting generated from AP invoices only. Use this page for invoice accounting, and the general page for SLA setup across modules.

An accounting event is the trigger SLA accounts against — for example an invoice being validated, adjusted, cancelled, or having a prepayment applied. Each event class maps to journal-line rules that build the entry. Testing means confirming the right event is raised and that it produces the expected journal.

Draft mode previews the journal without committing it, so you can review the accounting before it is final. Final mode commits the entry and makes it eligible for transfer to the ledger. Tests should confirm draft entries are not transferable and that a final run supersedes any draft without creating a duplicate.

You provision an invoice that should derive a known set of accounts, run Create Accounting, and compare each generated line's account combination against the CCID the SLA rules should produce. This catches a mis-configured derivation rule that would otherwise post thousands of journals to the wrong account.

A non-PO invoice debits the distribution expense account and credits liability. A PO-matched invoice instead relieves the purchase accrual and books invoice price variance and, where currency differs, exchange-rate variance. Both event classes need their own tests because the accounts and the variance handling differ.

Tax accounting tests confirm that recoverable tax posts to the recoverable tax account and that non-recoverable tax is added to the item cost or expense, per your recovery configuration. Because tax accounting depends on tax setup, these cases are re-run whenever tax rules or rates change.

Cancelling an accounted invoice should raise a reversal event that offsets the original journal and clears the liability. A test asserts the reversal is generated and nets to zero against the original — the common defect being an original entry left live after cancellation, overstating the liability.

You assert every tie point in the chain: distribution total to line total, subledger journal to invoice, debits to credits, GL journal to subledger journal, and posted balance to the liability control account. Any point that does not tie is a reconciling item, and testing catches it at its source rather than at close.

If an invoice's accounting date resolves to a closed GL period, Create Accounting cannot post the event and it stays unaccounted. Tests cover accounting date against period status so these events are caught before close — an unaccounted invoice is a common cause of a subledger not tying to the ledger.

Yes. Oracle runs Create Accounting as an ESS program as well as from the UI. A complete suite drives both and confirms they produce the same journals, because the ESS program is the path most tenants use at close and any divergence there is a control gap.

On every Oracle quarterly update, and after any change to SLA rules, account derivation, the chart of accounts, tax setup, accrual or match options, or ledger and period configuration. Because accounting feeds the ledger, testing after these events protects against silent drift that would otherwise surface only at reconciliation.

Each test needs an invoice engineered to raise a specific event — a PO match that books variance, a prepayment application, a foreign-currency invoice, a credit memo. SyntraFlow's Oracle Data Vault provisions the suppliers, POs, receipts, tax codes, and prepayments so each accounting test produces the intended event reliably.