The accounts receivable subledger is one of the most common sources of audit complexity, and also one of the most commonly under-tested. Not because auditors don't know they should reconcile it, but because the reconciliation approach most firms use was designed for clients with 500-row AR aging reports — and many clients now have AR populations an order of magnitude larger, spread across ERPs, billing systems, and customer payment portals that weren't designed to talk to each other.
There are three approaches in common practice, with materially different scalability profiles. This piece describes each and explains where the first two break down.
Approach 1: The Spreadsheet-Based Reconciliation
Export the AR subledger balance report from the ERP. Export the AR general ledger account balance from the trial balance. Open both in Excel. Compare totals. If they agree, document the reconciliation. If they don't, investigate the difference.
This approach works when the AR subledger is a single, homogeneous population — all recorded in the same ERP, all in the same currency, all with clear account mapping between the subledger and the GL control account. It produces a clean reconciliation that satisfies the audit objective with minimal effort for clients that fit this profile.
It breaks down in three scenarios that are increasingly common in the mid-market: multi-entity consolidations where AR is aggregated across subsidiaries with different AR systems, companies with separate billing platforms that post summary entries rather than line-level detail to the ERP, and clients with customer-specific payment portals (common in software and subscription businesses) that maintain their own receivables records independently of the ERP.
In all three scenarios, the spreadsheet comparison of subledger total to GL total will agree even when the underlying data has integrity problems — because the integrity problems are symmetric. If the billing system exports $2.4M of AR to the ERP but the ERP's own subledger shows $2.4M, the reconciliation passes even though you've only verified the transfer, not the completeness of the original billing system's data.
Approach 2: The Three-Way Reconciliation
An improvement on Approach 1: reconcile the AR subledger to the GL control account, and also reconcile the AR subledger to the billing system or source transactions that should be driving it. This requires obtaining a detailed transaction listing from the billing system and tracing it to the ERP's AR subledger at the transaction level.
For clients with separate billing platforms, this involves getting an export from the billing system (Stripe, Zuora, Salesforce Billing, or a proprietary billing tool), mapping the transaction IDs and amounts to the ERP's AR entries, and identifying items that appear in the billing system but not in the ERP's subledger (revenue recognized without a receivable) or items in the ERP's subledger that can't be traced to the billing system (receivables with no documented invoice basis).
This is the right approach conceptually. The execution challenge is data volume and mapping complexity. For a SaaS company with 10,000 customers and monthly billing, a full year's transaction file might have 120,000 rows. Tracing that to the ERP's AR subledger manually is a multi-day task. It's often abbreviated in practice — a sample trace rather than a complete reconciliation — which means the completeness objective isn't actually met.
Approach 3: Programmatic Reconciliation via Database Comparison
The third approach doesn't start from the reports. It starts from the underlying data tables in both systems and builds the reconciliation from the transaction-level data upward.
In NetSuite, the relevant tables are the Transaction and TransactionLine tables (for GL-side data) and the Invoice, CreditMemo, and CustomerPayment transaction types (for the subledger-side data). A SuiteQL query joining these transaction types to the Account table on the AR control account produces a ledger-level AR file that isn't mediated by any NetSuite report's filter settings.
For a Stripe billing integration, the Stripe API's charges and invoices endpoints return the complete transaction population directly. For Zuora, the same applies via the Zuora REST API on the Invoice and Payment objects. The programmatic extracts from both systems are then compared at the transaction ID level — matching billing system invoice IDs to ERP receivable transaction IDs — to produce a line-by-line reconciliation that identifies genuine gaps rather than just total-to-total agreement.
The output is a reconciliation file that shows: matched transactions (billing system ID = ERP AR entry, amounts agree), timing differences (transaction in billing system, not yet in ERP — expected for current-month invoices), unexplained items in the ERP with no billing system match, and unexplained items in the billing system with no ERP match. The last two categories are where audit findings originate.
Why the First Two Break Down at Scale
The scaling limitation of Approaches 1 and 2 is not computational — Excel can handle 120,000 rows with some care. The limitation is the hours required to perform meaningful analysis on a complete-population comparison when the data is spread across incompatible formats from multiple source systems.
Approach 1 abandons completeness testing in favor of total-to-total agreement, which proves nothing about the underlying data quality. Approach 2 achieves completeness conceptually but requires sampling in practice because the full trace is too time-intensive. Both leave coverage gaps that in the current environment — where mid-market companies routinely use three to five distinct systems for billing, collections, and ERP recording — are material.
Approach 3 eliminates the manual comparison work. The reconciliation runs against the API extracts rather than against spreadsheet exports, which means the mapping from source transaction to GL entry is done programmatically rather than by a staff auditor running VLOOKUP formulas. The auditor's time is spent reviewing the exceptions — the items that the programmatic reconciliation couldn't match — rather than performing the match itself.
AuditPulsar's Reconciliation Engine
The ledger reconciliation feature in AuditPulsar implements Approach 3 for the ERP-side component. The platform extracts the AR subledger population from SAP, NetSuite, or QuickBooks Enterprise via the same connectors used for journal entry testing, and builds the subledger-to-GL comparison programmatically from the underlying tables.
For the billing system comparison, the platform currently accepts direct API connections for Stripe and Zuora and CSV imports for other billing systems. The matching algorithm uses transaction IDs as primary keys, with fallback matching on invoice date and amount for clients where transaction IDs aren't consistent between systems. Unmatched items are surfaced in the exceptions report with the source data from both systems, giving the auditor the information needed to evaluate whether each exception represents a timing difference, a recording error, or a genuine discrepancy.
The reconciliation report that the platform generates includes the complete population from both systems, the match status of each item, and the auditor's dispositions from the review session. It's formatted as a workpaper exhibit and includes the metadata needed to satisfy the documentation requirements under AU-C Section 330 for substantive analytical procedures.
The Practical Starting Point
Not every client warrants a full Approach 3 reconciliation. For clients with a single ERP, no separate billing platform, and an AR subledger under 5,000 items, Approach 1 with reasonable completeness testing is defensible. The question to ask is: what's the distance between the billing transaction and the ERP's AR entry? If a human manually creates each invoice in the ERP based on a billing event, the AR population starts in the ERP and a subledger-to-GL comparison is the right procedure. If invoices are generated by a billing system and posted to the ERP via an automated interface, the completeness question requires validating the interface — and Approach 3 is the only way to do that rigorously at scale.
The clients where the interface-based billing model is common — SaaS, subscription businesses, companies using Salesforce CPQ with NetSuite — are exactly the clients where AR complexity has outpaced the procedures most firms are still applying. Closing that gap starts with recognizing that a subledger-to-GL reconciliation is not the same thing as a billing system-to-GL reconciliation, and only one of them addresses the completeness risk that matters.