JDE GL to Cardex Integrity With Claude Code

Why this break happens at all

Two systems of record, one inventory transaction, one chance to disagree.

Every inventory transaction — receipt, issue, transfer, adjustment — is supposed to write to F4111 and post an offsetting entry to F0911 through the AAIs (4110 inventory/COGS, 4220 variance). Most of the time it does. The break shows up when someone posts a manual journal entry straight to an inventory G/L account, bypasses standard cost update, or reverses a receipt in one system without the matching reversal in the other. None of that throws an error. It just sits there until month-end reconciliation finds a number that doesn't tie.

Before → after

A real one: branch/plant inventory value doesn't match the GL account balance.

What the controller actually has, day one

Branch/Plant 30 — Finished Goods GL account 30.1241.INV1 balance (F0902/F0911): €412,880.15 Cardex on-hand value, same branch (F4111 quantity × F4105 cost): €409,114.60 Difference: €3,765.55 — unexplained

What Claude Code drafts as the reconciliation query

-- Step 1: G/L postings to the inventory AAI account outside standard inventory update SELECT GLDOC, GLDCT, GLEXA, GLAN8, GLAA, GLDGJ FROM F0911 WHERE GLMCU = '30' AND GLOBJ = '1241' AND GLDCT NOT IN ('IR','IT','II','OV') -- doc types the inventory module itself would post ORDER BY GLDGJ; -- Step 2: Cardex entries in the period with no matching F0911 line by document number SELECT LEDOC, LEDCT, LEMCU, LEITM, LETRQT, LEAEXP FROM F4111 WHERE LEMCU = '30' AND LETRDJ BETWEEN @PERIOD_START AND @PERIOD_END AND LEDOC NOT IN (SELECT GLDOC FROM F0911 WHERE GLMCU = '30' AND GLOBJ = '1241'); -- Step 3: cost method check — Cardex extended cost recomputed at F4105 current cost -- vs. the cost actually used on each Cardex line (catches a mid-period cost change -- that updated F4105 but didn't retroactively touch existing Cardex rows).

What the query actually finds

Three break patterns cover almost every case.

Pattern	Signature	Fix
Manual G/L journal to the inventory account	F0911 document type `JE` hitting the 4110 AAI account, with no corresponding F4111 movement	Reverse or reclassify the manual entry — inventory accounts should only move through the inventory module, never a direct journal.
Reversed in one ledger, not the other	An F4111 line with a matching F0911 line whose amount doesn't net to zero after a return or correction	Rerun the reversal transaction through the inventory module so both ledgers move together.
Mid-period standard cost change	F4105 cost differs from the cost actually posted on existing F4111 lines for the same item/branch	Confirm whether a cost revaluation (P4105) should have been run — a revaluation posts the catch-up entry to both ledgers; an unmanaged cost edit doesn't.

Where the line is

Claude Code finds and explains the break. It never posts the fix.

Pull both ledgers for the period and branch/plant in question.
Read-only SQL against F0911, F4111, and F4105 — no write access, ever, to inventory or GL tables.

Match by document number and amount, surface what doesn't match.
The output is a short list of specific document numbers and amounts — not "the accounts are off by €3,765.55," but exactly which three transactions caused it.

Classify each break against the known patterns.
Manual journal, unmatched reversal, or cost-change gap — each points to a different corrective action and a different person who needs to sign off.

Controller or JDE developer posts the correcting entry.
Through the proper module — a journal entry, a reversal, or a P4105 revaluation — never a raw table update.

Why this matters more than a clever query

A GL-to-Cardex break is a closed-books risk, not a nuisance.

It blocks close

Finance can't sign off on a balance sheet where inventory value and the GL account disagree — the whole month-end calendar backs up behind one unexplained variance.

Manual tracing doesn't scale

A controller tracing this by hand is checking hundreds of document numbers by eye. The logic is simple; the volume is what makes it slow without a query doing the join.

It catches the root cause, not just the symptom

A plug journal entry makes the balance sheet tie without fixing why it broke — the same variance reappears next period until the actual pattern is found.

Month-end won't close over an inventory variance

Send me the branch/plant and the period.

I'll trace the specific documents causing the break before your next close deadline.

Reach me on WhatsApp↗

When the GL and the Cardex disagree,
nobody can close the month.