We Put an AI Anomaly Detector Inside BC's Posting Engine — Before Every Journal Entry Commits
Codeunit 12 in Business Central is where financial reality is written. When a sales invoice posts, when a payment is applied, when a journal is committed — it all flows through COD12's PostJournalLine procedure before touching the G/L Entry table. It is the most consequential codeunit in the platform.
We put an AI between the journal line and the ledger.
The Problem We Were Solving
Our client — a distribution group running Business Central across four legal entities — had a chronic problem with miscoded expenses. Junior finance staff were posting freight costs to incorrect G/L accounts, VAT was being posted against wrong tax groups, and intercompany transactions occasionally hit the wrong dimension values.
Standard BC validation stops at format and mandatory fields. It has no way to know that posting a freight invoice from a Saudi vendor against a zero-VAT code is almost certainly wrong, or that a specific G/L account should never receive entries from the Purchasing journal. We needed a layer that understood context, not just format.
The Architecture
BC's publisher-subscriber event model in AL gives us a clean extension point: OnBeforePostJournalLine. We subscribed to this event and added a real-time classification call to Azure OpenAI before the entry reaches the ledger. The classifier receives a structured payload — account number, journal type, amount, dimension values, vendor country, VAT posting group, and a rolling 90-day context of similar entries from the same user and vendor. It returns a confidence score and, when above threshold, a specific anomaly description in plain English.
How We Handle False Positives
The UI intervention is deliberately lightweight. Below 0.70 confidence, the entry posts silently — we do not interrupt the finance team with low-confidence noise. Between 0.70 and 0.85, a non-blocking notification appears in BC's notification bar. Above 0.85, a confirmation dialog surfaces with the specific anomaly and asks the user to confirm or re-examine. The threshold is configurable per company, per journal template.
Results After Four Months
- Miscoded G/L entries at month-end: down 76%
- VAT posting errors requiring reversal: down 91%
- Average time to identify and reverse a posting error: from 4.5 hours to 22 minutes
- False positive interruptions per user per day: 1.2
The AI is not replacing the accountant's judgment. It is the experienced colleague who looks over the junior's shoulder before they click Post — the one who says "are you sure about this?" when something looks off. That colleague used to cost a senior salary. This costs API tokens.
Tired of Month-End Posting Corrections?
This pattern can be implemented in any BC environment. The integration takes 3–5 days. The model training on your specific posting patterns takes another two weeks.
Talk to Our BC Team →