Oracle Invoice Distribution Testing

A distribution is the level at which an invoice line is charged to accounting. Each distribution carries an amount, an account combination, and any cost centre, project, asset, or tax attributes for that charge. The distributions on a line must sum to the line total, and they become the input Subledger Accounting turns into a journal.

Distribution testing covers the accounting inputs — how distributions are created, defaulted, allocated, and balanced. Journal generation, SLA account derivation, GL transfer, and reconciliation are the accounting outputs, covered on the Invoice Accounting Testing page. This page stops where the distributions are handed to SLA.

In several ways: PO-derived distributions inherit the account and attributes from the matched purchase order; non-PO distributions are entered manually; distribution sets apply a pre-defined split by percentage or amount; and Oracle generates tax, freight, miscellaneous, and withholding distributions automatically. A single line can expand into many distributions.

Balancing means the distributions on a line sum exactly to the line amount. If they don't, Oracle raises a distribution variance condition and the invoice cannot be validated or accounted. Because a total-level check can hide a distribution-level imbalance, asserting the sum on every case is one of the highest-value distribution tests.

A full distribution set defines both the accounts and the percentage split, so applying it produces balanced distributions automatically. A skeleton set defines only the accounts, and the user enters the amounts. Both should be tested: the full set for correct splits totalling 100%, the skeleton set for correct account defaulting with balanced entered amounts.

For PO-derived distributions, assert that the invoice inherits the charge account and any multi-distribution split from the matched PO. For non-PO distributions, assert that a manually entered account is valid, accepted, and balances to the line. The two paths default accounts differently, so both need explicit coverage.

By entering a non-existent or end-dated account combination and asserting Oracle rejects it — at entry or through a validation error — rather than accepting it. Cross-validation rules should also be tested: a prohibited segment pairing must be blocked. These negative tests confirm the account controls actually fire.

Tax distributions are generated by tax calculation and should be checked for the correct account and recovery treatment. Freight and miscellaneous charges are allocated across item lines by a configured method, so the test asserts the allocation split lands in the right cost centres. Tax calculation itself is covered on the Tax Testing page.

Assert that project-enabled distributions carry a valid project, task, and expenditure type, and that asset-tracked distributions have the track-as-asset flag and clearing account set. A missing or invalid attribute means the cost is not captured to the project or asset downstream, so the attribute set is checked on the specific distribution that should carry it.

When an amount is split unevenly — a percentage allocation that doesn't divide cleanly — a sub-cent remainder arises. Oracle places the remainder on one distribution so the total still balances. The test confirms the distributions sum exactly to the line and that no penny leaks, which otherwise surfaces as a reconciliation variance later.

For a correction, reassign the account on a distribution and assert the new account applies while the line still balances. For a reversal, assert that an offsetting distribution is created and the net position is correct. Both are common sources of new imbalances, so balance is re-checked after the change.

Yes. Distributions loaded through FBDI or the REST API should be tested by comparing the imported account and attributes against the source payload. Integration mapping is a frequent failure point — a source account that maps to the wrong combination introduces bad data at scale — so import parity is asserted against the known source.

The chart of accounts and cross-validation rules, distribution sets, Payables and invoice options, project and asset setup, and the ledger, business unit, and cost-centre calendar. When these drift between environments, a distribution test can pass against the wrong reality. Configuration Intelligence compares them so a pass reflects correct setup.

On every Oracle quarterly update, and after any change to the chart of accounts, cross-validation rules, distribution sets, project or asset setup, or the import mapping. Because distributions are accounting inputs, a silent change to defaulting reaches the ledger before it is noticed, so release-scoped regression on distributions protects against undetected drift.