Your Oracle Fusion AP aging report is not showing what it should. The numbers do not match what AP knows is outstanding. Suppliers that have been paid in full are showing open balances. Invoices with 60-day terms are appearing in the overdue bucket at day 35. The treasury team does not trust the report, so they maintain a parallel spreadsheet—which defeats the purpose of going live on Oracle Fusion in the first place.

I have rebuilt AP aging reports for organizations ranging from single-entity mid-market companies to global enterprises with 40+ business units and 15 currencies. The report is supposed to be straightforward. It almost never is after go-live, because the default configuration makes assumptions that do not match how most AP teams actually think about aging. A Reporting Sprint can rebuild your AP aging report with correct logic, validated output, and proper currency handling in 5–7 business days.

Here is what the report should show, and the five root causes that make it wrong.

What a Correct AP Aging Report Shows

A properly built AP aging report answers one question: how much do we owe, and how overdue is it? The output should show outstanding payable amounts broken into aging buckets—typically Current, 1–30 days, 31–60 days, 61–90 days, and 91+ days—grouped by supplier and optionally by business unit. Each invoice line item should appear in exactly one bucket based on how many days past due it is. Fully paid invoices should not appear. Cancelled invoices should not appear. On-hold invoices may or may not appear depending on the business requirement, but that decision should be explicit, not accidental.

When this report is wrong, AP teams cannot answer basic questions: Which suppliers are we most overdue with? What is our total exposure past 90 days? Are we at risk of late payment penalties? These are questions that should take seconds to answer. Instead, the team exports raw data, applies manual filters, recalculates aging in Excel, and produces an answer hours later.

Root Cause 1: Invoice Status Inclusion

Oracle Fusion invoices move through multiple statuses: Validated, Approved, On Hold, Cancelled, Fully Paid, Partially Paid, Never Validated. The AP aging report should only include invoices with an open liability—meaning the remaining amount is greater than zero and the invoice is not cancelled or fully paid.

The seeded Oracle Fusion AP aging report and many OTBI analyses built during implementation do not filter invoice status correctly. Common mistakes:

  • Including fully paid invoices. If the report filters on invoice creation date but does not check whether the invoice has been fully paid, zero-balance invoices appear in the aging buckets with a $0 amount or, worse, with the original invoice amount if the payment application is not reflected in the data source.
  • Including cancelled invoices. Cancelled invoices should never appear. But if the report queries the AP invoices table without filtering on invoice status, cancelled invoices are included. Their amounts inflate the total outstanding balance.
  • Excluding on-hold invoices. Some implementations filter out on-hold invoices because they are “not ready to pay.” But they still represent a liability. Whether to include or exclude them is a business decision, but it must be deliberate. If the report silently excludes them, the aging total understates the actual payable balance.

The fix

Filter on invoice status to include only Validated and Approved invoices with a remaining amount greater than zero. Add an explicit parameter for on-hold invoices so users can toggle their inclusion. Exclude Cancelled and Never Validated invoices unconditionally.

Root Cause 2: Aging Date Calculation

This is the root cause that generates the most confusion. The AP aging report calculates how many days an invoice has been outstanding, but “outstanding since when” depends on which date field is used:

  • Invoice date — the date the supplier issued the invoice. Using this as the aging basis means aging starts the moment the invoice was created, regardless of when payment is actually due.
  • Due date — the date payment is due, calculated from invoice date plus payment terms. This is what most AP teams expect. An invoice is “current” if the due date has not passed, “1–30 days overdue” if the due date was 1–30 days ago, and so on.
  • Accounting date — the date the invoice was accounted in Oracle Fusion. This is the GL posting date, which may differ from both the invoice date and the due date.

If the report ages from invoice date but users expect aging from due date, every invoice with payment terms longer than Net-0 will appear more overdue than it actually is. An invoice dated January 1 with Net-30 terms is not overdue on January 20—but a report aging from invoice date will show it as 20 days old, potentially in the “1–30 days” bucket.

The fix

Use due date as the aging basis. Calculate aging as: Report Run Date minus Due Date. If the result is negative (due date is in the future), the invoice is Current. If positive, place it in the appropriate bucket. Make the aging date field configurable so users can switch between invoice date and due date if needed for different analyses.

Root Cause 3: Payment Terms Not Factored

This is closely related to Root Cause 2 but manifests differently. Even when the report uses due date for aging, the due date itself may be wrong if payment terms are not correctly applied to the invoice.

In Oracle Fusion, payment terms are assigned at the supplier site level and can be overridden at the invoice level. If a supplier is set up with Net-60 terms but the payment terms on individual invoices default to Net-30 (due to a site-level misconfiguration or a data migration error), the due dates will be 30 days too early. The aging report will show invoices as overdue when they are not.

Another common issue: invoices entered with the wrong payment term during data migration at go-live. Thousands of historical invoices loaded with default Net-0 or Net-30 terms when the actual supplier agreements specify Net-45 or Net-60. Every one of these invoices will age incorrectly.

The fix

Audit the payment terms on open invoices against supplier agreements. For invoices with incorrect terms, update the payment terms at the invoice level (which recalculates the due date) or apply a correction adjustment. For the report itself, validate that the due date column is being derived from the payment terms calculation, not hardcoded or defaulted.

Root Cause 4: Multi-Currency Conversion

For organizations operating in multiple currencies, the AP aging report must convert foreign-currency invoices to a common reporting currency. This introduces three variables that, if misconfigured, make the report unreliable:

  • Rate type. Oracle Fusion supports multiple exchange rate types: Spot, Corporate, User-defined. If the report uses Spot rate but finance expects Corporate rate, the amounts will differ. Corporate rates are typically set once per period and provide consistency. Spot rates fluctuate daily.
  • Rate date. Which date is used to look up the exchange rate? Invoice date, due date, report run date, or period-end date? Each produces different converted amounts. For a month-end AP aging report, period-end rate (last day of the reporting period) is typically the correct choice.
  • Missing rates. If no exchange rate exists for a given currency pair on the specified date, the invoice either shows as zero (suppressed), shows in its original currency (mixing currencies in the total), or throws an error. All three outcomes are wrong. The report should flag missing rates explicitly.

The fix

Standardize on a single rate type and rate date for the AP aging report. For most organizations, Corporate rate as of period-end date is the correct choice. Configure the report to flag invoices with missing exchange rates rather than silently converting them to zero or leaving them in the original currency. Add a currency conversion summary section that shows the rate used for each currency pair so the output is auditable.

Root Cause 5: Period-End Cutoff Timing

The AP aging report is a point-in-time snapshot. But “point in time” is ambiguous in Oracle Fusion because multiple processes affect invoice balances, and they do not all complete simultaneously.

  • Payments processed but not accounted. A payment batch was run on the last day of the period, but the Create Accounting process for payments has not yet executed. The invoices are technically paid, but the payment has not been applied in the subledger. The aging report shows them as open.
  • Invoices received but not validated. Invoices scanned and entered into the system but still in “Never Validated” status. They may or may not represent a real liability depending on when they are validated and backdated.
  • AP accruals pending. The receipt accrual process (for three-way matched invoices) has not been run. Received goods without matched invoices are not reflected as a liability in the report, understating the total AP exposure.

The fix

Align the AP aging report run date with the completion of all period-end AP processes. The report should not be run until: all payment batches are fully accounted, all invoices for the period are validated and approved, and receipt accruals are processed. Document the cutoff process and build it into the period close checklist. Add a report parameter for “as-of date” so users can run the aging report as of the last day of the closed period rather than the current system date.

How a Reporting Sprint Rebuilds This in a Week

A Reporting Sprint for the AP aging report follows a focused sequence: audit the current report logic (data source, filters, aging calculation, currency handling), identify which of these five root causes are at play, rebuild the report with correct logic, validate the output against the AP subledger trial balance, and deliver a tested report with documentation. Total elapsed time is typically 5–7 business days. Your AP team gets a report they can trust for the next close cycle—not next quarter.