Skip to content

A/P Open Item report versus Aging report

Adapted from the Macola® accounting technical note "A/P Open Item Report vs Aging Report" (APOPAGNG, Progression 7.5) and the Leahy Consulting support note on vendor aging buckets.

Macola® gives you two A/P reports that look similar and answer different questions. Using the wrong one is the most common reason a reconciliation refuses to work, and the vendor file's own aging buckets are a third set of numbers that agrees with neither.

The short version

Open Item report Aging report
Uses the G/L distribution date Yes — the cut-off date No
Can be used to reconcile A/P to the G/L Yes, and it is the only one that can No
Ages individual invoices No — vendor totals only Yes
Sort order Vendor number only Vendor name or vendor number
Aging parameters can be overridden No Yes
Minimum-balance filter No Yes
Credit-balance-only option No Yes

Use the Open Item report to balance. Use the Aging report to manage vendors and plan payments.

A/P Open Item report

The Open Item report is the report to reconcile the A/P subledger against the general ledger — it is the only aging report based on the distribution-to-G/L date. The detail for each vendor prints in invoice number order.

It does not age the document detail. Aging happens at vendor total level only. Printed in detail, the voucher reference line prints.

The three dates that decide what appears

Aging date ages the invoices. Leave Include items past aging date unticked and vouchers with invoice dates past the aging date do not print at all.

Cut-off date is the voucher's G/L distribution date. Any voucher distributed after the cut-off date is left off the report regardless of its invoice date. This is the field that makes the report reconcilable.

Check date interacts with both. An invoice paid before the cut-off date — not the aging date — still shows as open. The check itself prints only when Show Fully Paid Items is ticked and the check date is before the aging date.

The report can be run based on invoice date or due date.

Voided checks and cancellation vouchers are reconciling items

When a check is voided in a period other than the one it was posted in, the voucher becomes open again as of its original invoice date. Both voided checks and cancellation vouchers have to be treated as reconciling items — see Reconciling A/P with the general ledger.

A/P Aging report

The Aging report is the tool for tracking vendor balances and working out who to pay. It ignores when a voucher was distributed to the G/L, which is exactly why it cannot be used to reconcile.

It looks only at the aging date, and ages by invoice date or due date. It can be sorted by vendor name or vendor number, and the detail for each vendor prints in invoice number order.

Three print options:

  • Show detail — invoice amounts in one column, aged days for each invoice in another. No references or G/L account numbers print.
  • Show doc age detail — invoice amounts in one of four aged-bucket columns, with vendor subtotals in the same four columns.
  • Vendor summary aging — totals only.

Like the Open Item report it can include items past the aging date, and can show open items only or all records. Unlike the Open Item report it can be filtered to vendors with a credit balance, or to a minimum vendor balance.

The vendor file's aging buckets are a third answer

A frequent support call: the aging buckets on the vendor record do not match the aging report, and a vendor is calling about invoices they say are past due.

The vendor file's aging buckets are not what feeds the aging report

The aging report processes the open item file, using the aging definition in the A/P setup file and the parameters on the report screen. The buckets held on the vendor record are not dynamic — they are updated only when you run the aging process under the A/P Processes menu.

The other half of the problem is which date each side counts from. The A/P aging process calculates the vendor file's buckets from the invoice due date. If your vendor ages their receivables from the invoice date, the two will disagree by exactly the terms period, and their "past due" is your "current".

Worked example

Aging days are defined as 30/60/90/9999 for periods 1 through 4, and the vendor is on terms of net 30 with no discount. An invoice dated 1 January 2005 is due 31 January 2005. The aging process treats that invoice as current until 30 days past the due date — so through early March.

Your vendor, aging from the invoice date, sees anything from 31 January onward as past due.

To line the two up, change the aging day values in the A/P setup file to 0/30/60/9999. The same invoice then falls into the second aging period, and shows as past due.

Aging days in A/P setup are global

Changing them affects the aging of every vendor, not just the one that prompted the call.

Support & contact

Our team is glad to help with anything from a quick question to a full implementation.