Quick answer
When accounts payable does not match the general ledger, first check whether the reports cover the same date, accounts and transactions. Then investigate incomplete accounting or transfers, opening differences and entries outside AP. These are documented causes of reconciliation differences—not automatic reasons to post an adjustment. Build a transaction-supported reconciliation before correcting anything. (docs.oracle.com)
This workflow is for accountants, controllers and ERP teams investigating an AP aging-to-control-account difference. Start with read-only reports and transaction inquiries. Product examples below refer specifically to Microsoft Dynamics 365 Finance and, where stated, Oracle Fusion Cloud Financials; they are not interchangeable configuration instructions.
1. Establish exactly what you are comparing
Write a one-line reconciliation scope before investigating:
“Reconcile [legal entity], [AP control accounts], in [accounting currency], as of [date], using [report names and parameters].”
Do not assume that all vendor balances belong in one control account. In Dynamics 365 Finance, vendor posting profiles can assign different ledger accounts to individual vendors or vendor groups. Some transactions can also use a different posting profile from the default. Inspect the actual postings and relevant configuration. (learn.microsoft.com)
Create a report-parameter sheet:
| Parameter | Practical check |
|---|---|
| Entity and ledger | Confirm both extracts represent the same accounting population. |
| Cutoff date | Record the balance date, not just the report-generation date. |
| Account scope | List every control account included in the comparison. |
| Currency | Identify accounting, reporting or transaction currency explicitly. |
| Dimensions | Record department, business unit and other restrictions. |
| Vendor filters | Save the vendor selection and inclusion settings. |
| Run information | Retain generation time and any preparation-process request ID. |
For the working paper, use one sign convention: for example, show liabilities as positive credit balances on both sides. Preserve the original signed exports separately.
Expected result: another accountant can reproduce the two starting totals without guessing your settings.
2. Check cutoff dates, aging settings and report filters
Treat the balance date and the aging-bucket basis as separate checks.
Dynamics 365 Finance’s Vendor aging report has a Balance as of field and separate criteria for transaction, due or document dates. It also has options for negative balances, transaction-currency amounts and unsettled payments. Record these settings before deciding that the report represents the full AP population you need. (learn.microsoft.com)
Work through these checks:
- Match the AP balance date to the ledger cutoff.
- Confirm whether your report reconstructs historical balances.
- Inspect vendor, account and dimension restrictions.
- Review the treatment of vendor debits and unsettled payments.
- Export transaction detail, not only aging buckets.
- Compare reports generated from a consistent data state.
Report behavior is product-specific. Oracle’s reconciliation documentation, for example, states that its Payables Aging Report is current-date only, whereas the reconciliation report presents period-opening and period-ending balances. It also warns that intercompany selections can make those reports incompatible. Do not assume any report labelled “aging” is suitable for a historical ledger reconciliation. (docs.oracle.com)
Common mistake: posting a journal because a filtered aging total differs from an unfiltered trial balance. First rerun the reports with a documented, comparable scope.
3. Separate document status from ledger posting status
Follow each suspected transaction through its accounting stages. “Approved,” “accounted,” “transferred” and “posted” should be separate investigation fields, rather than one generic “complete” label.
Dynamics 365 Finance supports asynchronous and scheduled-batch subledger transfers. Under those methods, ledger recording depends on processing resources or the scheduled batch. A source transaction therefore needs a verified ledger voucher—not merely an apparently completed document workflow. (learn.microsoft.com)
For each exception, capture:
- Vendor and document number.
- Source transaction or voucher identifier.
- Accounting date.
- Accounting and transfer status.
- General-ledger voucher reference.
- Error or batch reference, if applicable.
Oracle likewise identifies unaccounted transactions and subledger journals not transferred or posted to the ledger as reconciliation causes. (docs.oracle.com)
For a suspected delayed transfer, ask the responsible ERP administrator to establish whether the existing transaction is queued, failed or already posted. Avoid creating a replacement invoice merely because a ledger search initially finds nothing.
Expected result: every relevant AP transaction either has matching ledger evidence or a clearly documented processing exception.
4. Find the first difference: opening balance or current-period activity
Use two separate tests:
Opening difference = Opening GL liability − Opening AP liability
Current-period difference = Closing difference − Opening difference
These calculations help direct the investigation. If the opening balances already differ, do not treat the whole closing difference as a current-month problem.
Oracle’s Payables to Ledger Reconciliation report separates beginning balances, ending balances and period activity. Its documented prerequisite is the Prepare Payables to General Ledger Reconciliation process, which generates the report data. (docs.oracle.com)
Build a movement schedule for each side:
| Movement | AP evidence | GL evidence |
|---|---|---|
| Opening balance | Prior cutoff balance | Prior closing control-account balance |
| Invoices and credits | Vendor transaction detail | Related liability postings |
| Payments | Vendor payment detail | Related liability postings |
| Currency adjustments | Revaluation detail | Revaluation vouchers |
| Other adjustments | Identified source records | Identified journal lines |
| Closing balance | Current cutoff balance | Current closing control-account balance |
For migration-related exceptions, obtain the approved conversion reconciliation and opening transaction files. Microsoft recommends reconciling migrated balances and open transactions to the legacy system and reconciling subledgers to the ledger before new transactions begin. (learn.microsoft.com)
Do not accept “historic difference” as a complete explanation. Assign an owner, identify the oldest available evidence and state what remains unverified.
5. Trace direct ledger postings and control-account changes
Review control-account journal lines by source, voucher, date, amount and posting user. Put entries without a vendor transaction link on an investigation list; do not automatically classify them as errors.
Microsoft recommends preventing manual entry to main accounts used in posting profiles because direct postings make subledger-to-ledger reconciliation harder. It also warns that changing a posting profile does not update previously posted transactions. (learn.microsoft.com)
For each suspect line, ask:
- What source document supports it?
- Should it have been posted through a vendor account?
- Is it an approved adjustment held outside the vendor subledger?
- Does an offsetting entry exist elsewhere?
- Was the account included in the original reconciliation scope?
If an account mapping changed, inspect transactions on both the old and new accounts. Use the posting actually recorded, rather than assuming today’s configuration explains every historical voucher. (learn.microsoft.com)
Common mistake: searching only for one entry equal to the net difference. Use that search as a lead, then reconcile gross exceptions separately; several unrelated items may offset.
6. Reconcile currency effects on the same basis
Label every extracted amount with its currency basis. Compare accounting currency with accounting currency—not a transaction-currency total with an accounting-currency control account.
In Dynamics 365 Finance, AP foreign-currency revaluation updates open vendor transactions and posts corresponding accounting entries to the general ledger. The process can be simulated before execution. (learn.microsoft.com)
For a currency-related exception, retain:
- Foreign-currency open amount.
- Accounting-currency carrying amount.
- Revaluation date and exchange-rate date.
- Revaluation voucher and control account.
- Report-generation time relative to processing.
Use the revaluation transaction history to explain movements. Microsoft documents that repeated revaluation can produce a reversal of the previous unrealized gain or loss and a new unrealized amount under the same voucher. (learn.microsoft.com)
Do not label a small unexplained balance “rounding.” Identify the transactions and documented rounding behavior first.
7. Build a numerical reconciliation and exception log
The following is an illustrative example, not a company result. Assume one entity, one control account, a September 30, 2026 cutoff, and USD accounting currency. Liability balances are positive.
The GL shows $128,400; the initial AP aging shows $125,000.
Initial difference: $128,400 − $125,000 = $3,400.
Investigation establishes these hypothetical facts:
| ID | Finding | Reconciliation treatment |
|---|---|---|
| E01 | Aging excluded $1,200 of vendor debit balances | Include them; AP liability decreases by $1,200 |
| E02 | A $600 AP credit memo has no posted GL voucher | GL exceeds AP by $600 until resolved |
| E03 | Unsupported $4,000 direct GL credit to AP | GL exceeds AP by $4,000 pending correction |
After correcting the report filter:
Corrected AP balance = $125,000 − $1,200 = $123,800
The supported reconciliation is:
| Reconciliation item | USD |
|---|---|
| Corrected AP balance | 123,800 |
| Credit memo not yet posted to GL | 600 |
| Direct GL credit | 4,000 |
| Explained GL balance | 128,400 |
The original $3,400 difference concealed $4,600 of accounting exceptions partly offset by a $1,200 reporting error.
Maintain a log with ID, amount, document/voucher reference, evidence, cause, owner, proposed action, approval and status. Link each adjustment proposal to its exception ID. Record reporting-only changes separately from accounting corrections.
8. Correct the cause, rerun and obtain review
Before posting any correction, confirm:
- Evidence: the cause is supported by transaction-level records.
- Completeness: the transaction has not already posted or been corrected.
- Route: the proposed action uses the appropriate originating process.
- Impact: vendor balances, tax, settlement and currency effects have been considered where relevant.
- Period: the accounting date follows the organization’s close policy.
- Approval: the authorized reviewer has approved the action.
- Traceability: original and corrective voucher references will remain linked.
For changes to posting configuration, Microsoft recommends nonproduction testing and reconciliation before and after the change. Its documented correction approaches include correcting and reposting through the originating subledger or using a separately identified adjustment account—not hiding an unexplained difference in the control account. (learn.microsoft.com)
After resolution, regenerate both reports using the saved parameters. Where Oracle’s preparation process supplies the reconciliation data, rerun that process as well. (docs.oracle.com)
Retain the original reports, exception log, approvals, correction references and final reconciliation. Obtain reviewer sign-off on any remaining supported reconciling items.
A matching total is not enough: the reconciliation should explain how the vendor balances connect to the ledger, with evidence someone else can follow.