How do I reconcile the AP sub-ledger to the general ledger at month-end?

It becomes a three-way check: the AP platform's authorized-and-posted invoice list, the ERP sub-ledger, and the GL control account. The platform-to-ERP leg should reconcile to in-transit items only (approved but not yet synced at the timestamp); the ERP sub-ledger-to-GL leg follows the classic method. Date-stamp both pulls identically - most "differences" are mismatched as-of times.

The sub-ledger is the invoice-level detail (every open vendor bill); the GL control account is the single summary balance those details roll into. They must agree by construction - divergence means something posted to one without the other.

In rough order of frequency: manual JEs posted directly to the control account, unposted or stuck batches, aging report parameters (date basis, status filters) that don't match the GL period, payments applied in one view but not the other, and FX revaluation. Work the list top-down; the first two explain most differences in every ERP.

Identify the JE, reverse it, and rebook through the sub-ledger (or to a different account if it never belonged in AP). Then close the door: most ERPs let you block direct posting to control accounts or restrict it to a system role - turn that on and route true adjustments through documented exceptions.

Yes, as default policy - the control account should move only via sub-ledger transactions. Enforce it with the ERP's account-level posting restrictions where available, and where not, with a monthly report of non-sub-ledger postings to the account routed to the controller.

Treat in-transit as a named reconciliation category: invoices approved in the AP platform but not yet posted to the ERP at the cutoff timestamp. List them, verify they posted in the following days, and accrue them if the period must close first. A platform with real-time posting status makes the list a report, not an investigation.

Establish one rule for where voids originate (ideally the AP platform, syncing the reversal to the ERP) so both systems record the same event once. Voids entered directly in the ERP while the AP platform shows the invoice open are the classic source of permanent one-sided noise.

Reconcile each control account to its own sub-ledger slice (by entity, by currency) rather than in aggregate - netting across accounts hides offsetting errors. A reconciliation summary tab rolling up per-account status gives the controller the single view without sacrificing the per-account discipline.

Reconcile in transaction currency first (sub-ledger detail to pre-revaluation GL), then layer the revaluation as its own explained item tying to the FX adjustment entry. The revaluation is a GL-level remeasurement, not a sub-ledger event - keeping the two layers separate is the whole trick.

Both source reports (aging and GL balance) with matching as-of dates, an itemized list of reconciling items with explanations and follow-up status, the aging tie-out math, preparer and reviewer sign-offs with dates, and links to support for unusual items. Same format every month - auditors trust consistency.

Batch-posting ERPs (GP is the classic) hold transactions in batches that fail on errors, interrupted posting, or user lock-outs, leaving sub-ledger activity that never reached the GL. Check the batch recovery/queue screens as a standing close step, and prefer posting paths that confirm completion rather than fire-and-forget.

Monthly at close is the floor. High-volume or multi-system environments benefit from a weekly (or continuous) variance check, because a difference investigated within days is one transaction - the same difference at month-end is an archaeology project.

Yes: an automated job compares sub-ledger totals to control balances daily, flags variances over a threshold, and pre-classifies known reconciling categories (in-transit, revaluation). Humans investigate exceptions instead of building the tie-out. The prerequisite is clean posting discipline - automation surfaces differences faster; it doesn't absolve them.

Stampli is built so this reconciliation stays boring: invoices are validated against ERP structure before posting, every export has a status AP can see, and failures surface as actionable errors rather than silent gaps. Because Stampli mirrors the ERP rather than maintaining a second accounting database, there's no parallel balance to drift - the ERP remains the source of truth and Stampli shows you exactly what has and hasn't reached it.