AR-to-GL close: classifying residuals so month-end can move

There is a particular shape of frustration that recurs in every AR-to-GL close. The matching is done. Two-hundred and forty-seven of two-hundred and forty-eight invoices have tied out cleanly to journal entries on the receipts side. The single remaining row is a ₹2,847 residual on the account of a customer who, the controller is reasonably certain, deducted TDS at source and netted a small GST credit note before remitting. The controller is reasonably certain. They are not certain enough to mark the recon resolved. The recon cannot move to ready-to-close until they decide. It is now the third day of the close, the team is in standup, and the question being discussed is whether ₹2,847 is a residual to accept or a break to investigate. The answer is the same answer it was on the second day. Nobody has time to chase the customer to verify, and the close cannot move without a decision. This is the third-day problem of AR-to-GL, and it is structurally a classification problem rather than a matching problem.

Most reconciliation tools have trained finance teams to look at match rate as the primary close-readiness signal. Match rate is the percentage of source rows that found a target row, and it is a useful upstream signal — a recon with a 60 percent match rate clearly has bigger problems to deal with first. But match rate as a close-readiness signal conflates two operationally different things. It mixes residuals that the close should absorb (TDS deductions, GST credit-note netting, write-off rounding, timing differences for receipts that will arrive next period) with breaks that the close cannot absorb (counterparty mismatches, duplicate document postings, configuration errors). At a 99 percent match rate, the unmatched 1 percent is some unknown blend of these two categories — and without a way to separate them, the controller has to manually triage every variance to decide which kind it is. The 1 percent is what eats the third day.

The taxonomy that makes the separation possible in ReconPe is a typed enumeration with eleven values, called FinanceOpsResidualClass. Six of the eleven are marked as not blocking the close: TIMING_DIFFERENCE, TAX_OR_TDS_ADJUSTMENT, GST_ADJUSTMENT, WRITE_OFF_OR_ROUNDING, OUTSIDE_CLOSE_PERIOD, and NOT_DUE_FOR_POSTING. Five of the eleven are marked as blocking: CUSTOMER_OR_VENDOR_MISMATCH, DUPLICATE_DOCUMENT, UNMATCHED_SOURCE_BREAK, UNMATCHED_TARGET_BREAK, and CONFIGURATION_OR_MAPPING_ISSUE. The blocker flag is encoded directly into the enum constant, not configured externally, because the categorisation reflects accounting reality rather than user preference. Each open exception in a FinanceOps reconciliation can be assigned to one of these eleven classes, and the close-readiness check looks not at the count of open exceptions but at whether all of them are classified and whether any of the classifications carry the close-blocker flag. A recon with twenty open TIMING_DIFFERENCE exceptions and zero unclassified items can move to READY_TO_CLOSE. A recon with one unclassified exception, or one DUPLICATE_DOCUMENT exception, cannot.

TDS is the dominant non-blocker residual in any Indian AR ledger of meaningful size. Section 194-O of the Income Tax Act requires marketplaces and payment aggregators to deduct one percent (or two percent in non-PAN cases) at the point of settlement. The deduction is real cash that the customer no longer remits to the seller; it is also a credit that the seller can claim against tax liability when it appears in Form 26AS. The reconciliation problem this creates is structural. The AR sub-ledger carries the gross invoice amount. The cash receipt is the net of TDS. The journal entry on the GL side typically books both — credit AR, debit cash, debit TDS receivable — but the booking happens in one pass while the matching happens against the cash leg only. A controller staring at a ₹98,000 receipt against a ₹1,00,000 invoice has to recognise the ₹2,000 gap as TDS rather than chase the customer for the difference. ReconPe's residual classification surface lets the controller tag the residual as TAX_OR_TDS_ADJUSTMENT once and have the close move forward. After three such classifications for the same counterparty fingerprint, the system suggests the classification automatically on the next month's residual.

GST credit notes are the second-most-common non-blocker. A customer issues a credit note against a previously-billed invoice — for a returned good, a contractual rebate, a quality adjustment — and nets it against the next remittance. The seller's AR sub-ledger may not have processed the credit note as a separate entry yet; from the matcher's perspective, the cash receipt is short of the invoice by the credit note amount. The right classification is GST_ADJUSTMENT (because the adjustment carries a GST component that needs to be reflected in the seller's GSTR-1 amendment), the residual is non-blocker, and the close moves on. The historical alternative — refusing to close until the credit note is processed and re-posted on the AR side — is the kind of process discipline that sounds correct in a controls memo and produces three-day closes in practice.

The lifecycle that ties this together has six states: DRAFT, PROCESSING, AGGREGATION_REVIEW, BREAK_REVIEW, READY_TO_CLOSE, and CLOSED. DRAFT is the wizard-configured recon before it has been started. PROCESSING is the asynchronous matching pass, typically completing in seconds for under fifty thousand rows. AGGREGATION_REVIEW is the state where subset-sum candidate groups have been generated but await human confirmation; the recon cannot advance until the controller works through the queue, accepting groups that are correct and rejecting (or splitting) groups that are not. BREAK_REVIEW is the state where the remaining open exceptions need classification — each gets assigned to one of the eleven residual classes. READY_TO_CLOSE is the gate state: the recon has been classified end-to-end and no close-blocker classes are present. CLOSED is the terminal state, locked, audit-trailed, exportable. The transitions between states are deliberate and gated; a controller cannot skip BREAK_REVIEW by ignoring exceptions, and the system cannot move to READY_TO_CLOSE while a single exception remains unclassified.

Two design choices in the queue mechanics matter for how this feels in practice. First, the auto-approval gate for aggregation groups is intentionally conservative. A group is auto-approved out of the AGGREGATION_REVIEW queue only if its sum delta is within a half-paise of zero AND it contains twelve or fewer source rows. The reasoning is that delta-zero small groups are statistically unlikely to be wrong subset-sum solutions, and auto-approving them drains the trivial half of the queue without a click. Larger groups, or any group with a non-zero residual, always require a human decision because a wrong subset-sum match composed of unrelated rows that happen to sum to the same number is a pattern that a careful controller catches and a busy automation cannot. Second, the AGGREGATION_CANDIDATE exception type is excluded by design from the Discrepancy Workbench, the surface where controllers triage value mismatches and tolerance breaches. An aggregation candidate is a proposed match awaiting confirmation; it is not a discrepancy to investigate. Mixing the two creates exactly the kind of cognitive noise that slows close cycles down, and the surface separation is what removes it.

The audit trail follows the same shape as the rest of the recon surface. Each open exception, each residual classification, each aggregation group acceptance, and each rejection logs the user identifier, the timestamp, and the resolution note. Reruns of the same recon on the same data produce identical groups and identical exceptions deterministically — no Monte Carlo, no LLM-on-the-matching-path, no irreproducibility. Statutory auditors who want to retrace the logic by which a particular ₹2,847 TDS residual was accepted can pull the row from the database with the user, time, and reason captured. SOX-environment teams use the same trail for control evidence. The audit story is not a bolt-on; it is the same data structure the close-readiness gate uses, which is what makes it actually defensible under audit rather than reconstructed at audit time.

Stateful memory across periods compounds the value of classification. A controller who classifies a particular vendor's recurring ₹847 TDS residual as TAX_OR_TDS_ADJUSTMENT in May does not have to re-classify the same residual in June. The organisation-wide exception pool — fingerprinted by SHA-256 over (counterparty, amount, sign), aged out at 180 days — links new exceptions to historical residuals when the fingerprint matches and surfaces the prior classification as a suggestion. After three confirmed classifications for the same counterparty pattern, the system tags the counterparty with a recurring-residual annotation, and the next month's exception arrives pre-classified for the controller to confirm rather than decide from scratch. The work shifts from classifying each variance fresh to confirming that a previously-classified pattern still holds, and the time on the BREAK_REVIEW queue collapses by an order of magnitude after the first two or three months of use on the same counterparty population.

The metric a controller should be using to evaluate AR-to-GL recon health is not match rate, which is what reconciliation tooling has trained the industry to focus on, but classification rate — the percentage of open exceptions that have been assigned to a residual class. A recon with a 99 percent match rate and a 70 percent classification rate cannot move to READY_TO_CLOSE; the unclassified 30 percent of exceptions might be benign or might be blocking, and the system cannot tell which. A recon with a 96 percent match rate and a 100 percent classification rate, where the four percent of unmatched items are all classified as TIMING_DIFFERENCE waiting on next period's data, can close cleanly today. The shift in metric is small to describe and large to operate by — it is what compresses the close from three days of variance-chasing into half a day of confirmation. Match rate measures the matcher's job. Classification rate measures the controller's, which is the one that actually gates the close.