The debtors ledger says one number and the G/L control account says another, and nobody can explain the difference. Nine times out of ten someone posted a journal straight to the control account. Why it happens, why it is so hard to unpick, and the one setting that stops it.
Every finance team that has run Business Central for a while has had the conversation: the aged debtors report says £412,380, the debtors control account in the general ledger says £409,130, and the auditors want to know why. The answer is almost always the same. Somebody posted a journal directly to the control account.
Business Central keeps two sets of books for customers, suppliers, stock, bank and fixed assets. The sub-ledger is the detail: customer ledger entries (every invoice, credit note, payment and application, per customer), vendor ledger entries, item ledger entries and value entries, bank ledger entries, FA ledger entries. The general ledger is the summary: one control account per sub-ledger (Debtors Control, Creditors Control, Inventory, each bank account, Fixed Assets at cost and accumulated depreciation).
The two are supposed to agree to the penny, always. They do, as long as every posting to a control account comes through the sub-ledger: a sales invoice posts a customer ledger entry and, through the customer posting group, a G/L entry to the debtors control account, in the same transaction. The posting groups are the link: customer posting group says which G/L account is the receivables account; inventory posting group says which is the inventory account; bank account posting group says which is the bank G/L account.
A journal line posted with Account Type = G/L Account straight to the debtors control account creates a G/L entry with no customer ledger entry behind it. The G/L moves; the sub-ledger does not. From that moment the two disagree, and nothing in the system will ever bring them back on its own.
Because the G/L does not know it is wrong. The entry is a valid G/L entry on a valid account. There is no sub-ledger entry to point to, so no customer statement shows it, no aged report includes it, and no reconciliation report lists it as the cause. Finding it means listing every G/L entry on the control account and identifying the ones with no matching sub-ledger document: possible with the Source Code and Document Type fields (sub-ledger postings carry a source code such as SALES or PURCHASES; a journal carries GENJNL), tedious over a year, and miserable over five. And every month-end in between, someone has been reconciling around a known difference, which is the kind of thing that ends up in the due diligence findings.
On every G/L account card there is a field called Direct Posting. When it is unticked, the account cannot be posted to from a general journal or any G/L-account line on a document. It can still be posted to through the posting groups, which is exactly what you want for a control account: the system can post to it, people cannot.
Untick Direct Posting on: the debtors control account(s); the creditors control account(s); every inventory account (inventory, WIP, and the interim accounts if you use expected cost posting); every bank G/L account; fixed assets at cost and accumulated depreciation; and any other account that a posting group targets exclusively, such as the VAT accounts if you want VAT only ever to come from VAT posting setup. Then try to post a journal to one of them: Business Central refuses with "Direct Posting must be equal to Yes", and the person has to go and do it the right way.
It takes ten minutes. Most implementations do not do it because the implementer needed direct posting on during the opening balance load and nobody turned it off afterwards. Turn it off on go-live day, after the opening balances are reconciled, as a cut-over step.
Find the date the difference first appears by running the sub-ledger report and the G/L balance at each month-end back in time. From that month, list the G/L entries on the control account, filter out the source codes that come from the sub-ledger, and what is left is the journal postings. Decide for each what it should have been (usually a sub-ledger entry that still needs to exist, or a provision that belongs on another account), post the correction the right way, reverse the direct posting, and then untick Direct Posting so it cannot happen again. For a long-standing difference this is a day or two of a senior person's time; it is also the sort of thing a health check finds and prices.
The whole point of an ERP over a bookkeeping package is that the ledgers agree by construction. Direct posting to control accounts is the one thing that breaks that, and it is the one thing a single tick box prevents.
