AR and AP reconciliation: tying the subledger to the GL control account (and why they drift)

Someone learning NetSuite hit a step in the close that did not make sense: run the Aged AR and Aged AP reports and "reconcile" them to the general ledger. Their honest reaction — "I assume that the sub ledgers (accounts receivable and accounts payable) will always match the balance sheet" — is the right instinct and the trap at once. Usually they do match. The reason you reconcile anyway is the months they quietly do not, because the ways an AR or AP subledger drifts from its control account are invisible until you tie them out: a manual journal entry posted straight to the control account, an invoice booked into the wrong period, a payment applied to the wrong customer. None of it errors. The total just stops agreeing with the detail. Here is what actually makes them diverge, the method to tie the aging to the GL every close, and the second half of AP reconciliation that catches a bad invoice before you ever pay it.

Doesn't the subledger always equal the balance sheet?

Almost always — and "almost" is the entire reason the step exists. The poster's confusion is worth quoting because nearly everyone starts here:

I found this confusing since I assume that the sub ledgers (accounts receivable and accounts payable) will always match the balance sheet.

The mechanics are simple once you name the parts. Your AR control account is a single summary line in the general ledger; the aged AR report is the subsidiary ledger behind it — every open invoice, customer by customer — that should add up to that one GL number. They tie when every entry reaches AR through the subledger: an invoice raised, a payment applied. They drift the moment something touches the control account without going through a customer or vendor — a manual journal entry straight to AR, an entry stamped with the wrong date, a payment applied to the wrong account. The aging still totals what the invoices say; the GL totals something else; and the gap between them is the reconciliation. So the subledger does not "always match" — it matches when nothing bypassed it, and tying it out every close is how you prove nothing did.

What actually makes a subledger drift from the GL

Before you treat a subledger-to-GL gap as a mystery, know the short list of things that cause it. Every one of them is an entry that hit the control account on a different path than the detail did.

A commenter on that NetSuite thread landed near the right framing — that the exercise is "more of a 'review' of the sub ledger to make sure the right things are posted in the right period" — and that is half of it. It is a review, yes, but it is also a tie-out: when the aging and the control account disagree, one of the rows above happened, and "review" is how you find which. Another reply pointed at the most common culprit, dating: getting "the transaction date [to] match the actual date on the vendors document" is what keeps a bill from landing in the wrong period and breaking the tie in the first place.

How to reconcile AR or AP to the GL, step by step

The method is the same for both ledgers — receivables or payables — and it is a set-difference between the detail and the summary, run as of one date. Do it top to bottom.

1. Fix one cutoff date. Run the aged AR (or AP) report and the GL control-account balance as of the exact same date. A different "as of" on each side manufactures a difference that is not real.
2. Compare the two totals. The aging total should equal the control-account balance. If it does, you are not done — scan the aging for stale items, but the tie holds.
3. If they disagree, list the GL entries to the control account that have no match in the subledger. These are the manual journal entries and direct postings — the prime suspects.
4. List the subledger entries that fall in a different period than the GL. These are the wrong-date postings; re-date them to the document date.
5. Classify each difference by cause using the table above, and correct it on the side that is wrong — never plug the gap to force a tie.
6. Keep the reconciliation with the aging report and the GL detail attached, so next close starts from a proven balance.

The identity you are proving
----------------------------
  Aged AR report total   ==  AR control account balance   (same date)
  Aged AP report total   ==  AP control account balance   (same date)

When they disagree:
  difference  =  entries that hit the GL control account
                 without flowing through the subledger
                 +  subledger entries posted in the wrong period

Tying the subledgers to the GL is step four of a month-end close for a reason — it sits on top of cash and clearing, which you prove first. And it is a standard audit ask, not an optional nicety: the trail from the aging back to the control account is exactly the evidence an auditor wants when they test whether AR and AP are real.

The other half of AP reconciliation: match the invoice before you pay it

Tying AP to the GL proves what is on the books is consistent. It says nothing about whether a bill should have been paid in the first place. That is the second reconciliation on the payables side, and it runs before payment, not at close. Someone on r/Accounting, asking how accounts payable teams handle carrier invoices at volume, named it:

We process a lot of carrier invoices and manual reconciliation against POs is becoming a bottleneck. Are there tools or processes that work well for catching billing discrepancies before payment?

The control they are reaching for is the three-way match: before a bill is paid, line it up against the purchase order (what you agreed to buy) and the receiving record (what actually arrived). Quantity, price, and terms have to agree across all three. It is the same primary-ID discipline as any reconciliation — the PO number is the key that joins the three documents — and a mismatch is a billing error you catch before the money leaves, not after.

For freight specifically, the most useful reply in that thread flagged why a plain three-way match is not enough:

for freight, the hard part is matching the invoice against the rate card, accessorials, fuel surcharge, delivery zone, and exceptions. normal 2-way or 3-way matching catches duplicates and missing POs, but it won't

Right — and the gap they trail off on is the point. A standard match confirms the invoice ties to a PO and a receipt; it does not recompute whether the carrier billed the agreed rate. Carrier invoices need a fourth check against the rate card and accessorials, because the discrepancy is usually a correct-looking line at the wrong price, not a missing one. A doubled bill, meanwhile, is the duplicate the invoice number hides — it slips a one-to-one match when the second copy carries a slightly different number, and it inflates both the AP aging and the GL until someone tests for it.

Doing the tie-out in a spreadsheet

For a few accounts at monthly cadence, this is a spreadsheet job. Export the aged AR (or AP) detail to one sheet and the GL control-account activity to another, key both on the invoice or bill number, and match the two lists. The rows that appear in the GL but not the aging are your direct-to-control-account entries; the rows in the aging but not the GL are the wrong-period or unposted ones. That is the same missing-row check you would run on any two files, and it is the manual reconciliation method pointed at a subledger.

When the monthly tie-out outgrows the spreadsheet

A spreadsheet tie-out is right for a few accounts you close by hand. It strains when the subledgers carry thousands of open items, when the same reconciliation runs weekly, when multiple currencies revalue, or when someone else has to trust the result without rebuilding it — the same ceiling an inventory subledger hits against the GL at scale. The method does not change; you just want the matching rules and the classification preserved as a repeatable, auditable process rather than rebuilt from exports each month. If you reach for help there, keep the AI on the setup and the explanation and the arithmetic in code you can audit, so the tie between the aging and the GL stays one you can defend to an auditor.

← All writing