## TL;DR
A 3,812 break appearing right after a payment run means the run touched one ledger and not the other: payments posted to the GL through a manual journal or a different bank account mapping, invoices entered directly to the control account, or the payment run's accounting date fell in a different period from its subledger date. Reconcile by population, not by staring at totals: run the AP aging as of the GL period end and the control account detail for the same cut-off, then list items in one population but not the other. The difference will decompose into named documents. Correct each by reversing the wrong-side entry and reposting through the proper AP path, so subledger and GL move together from then on.

```text
AP subledger aging total does not tie to the GL control account by 3,812 after the payment run
```

## Use this when
- The AP aging total and the GL control account differ by a specific amount, here 3,812, first noticed after a payment run.
- Payments were made through more than one channel: ERP run, manual bank transfer, or a payment service.
- Direct journals to the AP control account are technically possible in your ERP configuration.

## Not for this skill when
- A single vendor's balance is disputed. Work the vendor statement reconciliation, not the control account.
- The difference existed before the payment run at the same amount. It is an older break; age it and work it as a brought-forward item.

## Steps
1. Freeze the comparison point: run the AP aging and the GL control account balance for the identical date, time and period cut-off. Verify: both reports describe the same population moment, so the 3,812 is a real break, not a timing artefact
2. Extract the GL control account line detail and the subledger open items, and match them in a spreadsheet or reconciliation tool by document number. Verify: unmatched lines on both sides are listed with amounts summing toward 3,812
3. Classify each unmatched line: payment posted one-sided, journal direct to control, invoice in a different period, or duplicate payment. Verify: every component of the difference has a cause and an owner
4. Correct each item through its proper path: reverse one-sided entries and repost via AP payments or invoices, never by plugging the control account. Verify: corrections post and the unmatched list shrinks item by item
5. Re-run both reports at the same cut-off and confirm the difference is zero, then save the reconciliation with the item explanations. Verify: aging and GL tie exactly and the reconciliation is filed as close evidence

## Variant phrasings
### AP aging does not tie to GL control account after payment run
The symptom as controllers phrase it.
### accounts payable subledger vs general ledger difference 3812 reconcile
The amount-led search form.
### payments posted to GL not subledger AP control account break
The most common one-sided cause.

Compatibility: AP subledger-to-GL reconciliation in SAP, Oracle, NetSuite, Dynamics and Sage, for control accounts fed by invoice and payment posting.

## Why it happens
The control account is only trustworthy if every AP event flows through the subledger, which alone keeps vendor-level detail. Payment runs break the tie when part of the run is executed outside the ERP (a bank portal payment, a payment processor, a manual journal to clear an urgent bill) or when the run's GL date and subledger date straddle a period end. The total difference is then exactly the value of the events that bypassed one side.

## Edge cases / pitfalls
- Period straddle differences reverse themselves next period; label them as timing in the rec so nobody corrects a non-error.
- Lock the control account against direct journals wherever the ERP allows it; prevention beats monthly archaeology.
- A difference that survives two periods at the same amount is a brought-forward break needing its own investigation, not a payment run issue.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EOspc76FYyPWQuyTEW4eXg