When Payables does not tie to the General Ledger
AP says one number, GL says another, and the report that should settle it has terms of its own. The owned tie runs nightly and names every difference.
1 AP facts, every invoice and payment, extracted whole. One side of the tie.
2 GL journal lines for the control account, every source tagged, so a manual journal cannot hide. The other side.
3 One query sums both sides per account and period. Its Airflow DAG runs nightly with sanity checks: duplicate keys, counts, null accounts. A failed check stops the load, not the close.
4 Both extracts land side by side in the top tier of your cloud box, the raw layer called bronze, and load straight down into the star.
5 The warehouse star is just a database in your own cloud: amounts joined to lookups, security joined on ledger. Oracle’s own report is documented in our catalog, open it here.
6 The answer is zero, or it is a name: the journal id, the source, the user, the day. Every ledger, daily, no Prepare job, and a difference drills to the journal that caused it.
deploys Everything ships from Git. One Oracle quirk to respect: uploading report artifacts resets folder permissions, so every deploy ends by reasserting them.
Oracle’s own terms for the report: the documented considerations, which state the Prepare process, the primary-ledger and non-adjustment limits, the difference causes, and the advice that says it all: do not let other sources post to Payables accounts.
answer AP 4,120,300 · GL 4,132,700 · off by 12,400: one manual journal, source Spreadsheet, posted 2:14pm, user named
◆ The report's terms, in full— what Oracle documents, and what it costs in close week.
| The term | What it means at 9pm on day two |
|---|---|
| Prepare must run first | The report reads a snapshot built by the Prepare Payables to General Ledger Reconciliation process. Forget the run, or run it early, and the report reconciles yesterday against today with a straight face. |
| Primary ledger only | Secondary ledgers and reporting currencies are outside the report's world. If the tie you owe the auditor lives there, the report cannot help. |
| Non-adjustment periods only | The adjustment period where year-end entries land is exactly where the report will not go. |
| Heavy, and close-week slow | At real transaction-line volume the Prepare process and the report become an event to schedule, not a question to ask, and past a point they simply time out. The tie becomes a monthly ceremony instead of a daily fact. |
◆ The four ways the tie breaks— Oracle's documented causes, and what each looks like.
| The break | The signature |
|---|---|
| Manual journals in the control account | Somebody posted straight to the Payables account from a spreadsheet. AP never heard of it, GL carries it, and the difference is exactly that journal. The most common break, and the reason Oracle's own advice is to close the account to other sources. |
| Unaccounted transactions | Invoices or payments that exist in AP but have not run through create accounting. AP counts them, GL cannot see them yet. |
| Other sources posting in | Integrations, conversions, or another module writing to the same account. GL grows, AP does not, and the source column names the culprit. |
| Timing across the boundary | A transaction accounted in one period and posted in another, or entered on the last day and accounted on the first. The difference reverses itself, but the auditor still wants it named. |
◆ The owned reconciliation, mechanics— both sides as extracts, the tie as a query.
| Piece | How it works |
|---|---|
| Both sides extracted | AP invoice and payment facts on one rail, GL journal lines for the control accounts on the other, both through the compliant bulk path, nightly. The same pipeline chassis as the supplement pipeline, and the security extract rides along. |
| The tie as a query | Sum AP by account and period, sum GL by account and period, subtract. Zero is the answer everyone wants; anything else joins back to the journal lines and returns id, source, user, and date. The difference is never a number alone, it is always a name. And volume is not a term: the same query at fifty thousand lines or fifty million, because a warehouse sums. The seeded report at that volume is the timeout in the problem zone. |
| No Prepare, no snapshot | There is no snapshot process because there is no snapshot: the query reads the loaded facts. Run it any hour, any ledger, any period, including adjustment periods. |
| Gates before anyone looks | Row counts against the manifest, duplicate keys, null accounts, and both sides' totals against yesterday. A failed gate stops the load and pages the pipeline owner, so a half-loaded night never masquerades as a broken tie. |
| Where it runs | A database in your own cloud, GCP, Azure, or AWS, with the security join filtering every answer by the asker's ledgers. The read-only Analyst watches the same query and flags a moving difference before day two. |
◆ A close-week walk-through— one difference, found and named in a minute.
Day two, 9pm. The control account shows AP at 4,120,300 and GL at 4,132,700, a 12,400 difference the old way would chase tomorrow with a fresh Prepare run. The recon query already has it: the GL side carries one line AP never produced, a manual journal posted that afternoon, source Spreadsheet, user named, 12,400 exactly. The controller reads the journal id off the screen, calls the desk that posted it, and the tie is explained before the coffee cools. Nothing was rerun. Nothing timed out. The report in Fusion stays what it should be, the official artifact for the file, while the daily question lives where daily questions belong.
Published clean-room: the pattern is shown, no client's SQL, structures, or naming appears here, and never will.
- control account
- The GL account a subledger posts into. The tie lives here.
- BICC
- BI Cloud Connector, Oracle’s bulk export service for Fusion data.
- Prepare
- The snapshot process Oracle's report requires before it can run.
- AP · GL
- Accounts payable, the general ledger. The two sides of the tie.
- DAG
- A scheduled chain of jobs. Airflow runs the nightly tie as one.
- DQ
- Data-quality checks. Dupes, counts, nulls, caught before the load.
- star schema
- One table of amounts joined to small lookup tables. The fast shape.
- ⋈
- A join. Security joins the amounts on ledger.