Somewhere in most companies that have integrated a financial system with inventory management, there's a quarter where the numbers didn't reconcile and nobody could immediately say why. The inventory system showed one value, the general ledger showed another, and reconstructing the discrepancy took days of tracing individual transactions. This isn't rare, and it isn't usually a sign the software is broken — it's almost always a sign the integration was designed around a handful of predictable, avoidable assumptions.
Here's what actually tends to break, and how to design around each one before connecting two systems.
Costing Method Mismatches
Business Central supports several inventory costing methods — FIFO, Average (a weighted, moving average), Standard, and Specific — and each one values inventory differently, with real consequences for how cost of goods sold gets calculated and posted to the general ledger. FIFO applies costs in the order inventory was received; Standard costing sets a predetermined cost and routes any variance from actual cost to dedicated variance accounts; Average uses a moving weighted calculation that updates with each purchase.
The integration problem shows up when a costing method is chosen without input from finance, or changed later without understanding the downstream reporting impact. A manufacturer using Standard costing, for instance, needs variance accounts properly mapped and reviewed regularly — skip that, and inventory variance quietly accumulates in an account nobody's watching until it surfaces as a large, confusing adjustment at year-end.
What to design around: Choose the costing method deliberately, with finance involved in the decision, and confirm variance account mapping is reviewed as part of regular close — not left to default settings from implementation.
Unapplied or Partially Applied Transactions
A common, quiet failure mode: inventory transactions that were never properly applied against their corresponding receipt or issue, leaving the system with entries that technically exist but aren't correctly linked to the transaction they relate to. This produces exactly the kind of discrepancy between inventory valuation and the general ledger that takes days to trace, because the underlying data isn't wrong exactly — it's just unresolved.
What to design around: Build a regular review cadence — not just at year-end — using tools like an Item Application Worksheet to catch and resolve unapplied entries close to when they happen, while the context is still fresh, rather than letting them accumulate.
Timing Mismatches Between Physical and Financial Events
Inventory can physically move — received, shipped, adjusted — before the corresponding financial posting catches up, especially in integrations that batch updates rather than processing them as transactions occur. In the gap between physical movement and financial posting, anyone pulling a report is looking at a snapshot that's technically inconsistent between the two systems, even though both will eventually agree once the batch runs.
What to design around: Understand exactly what your integration's timing model is — real-time, near-real-time, or batch — and make sure anyone relying on reports understands what "as of" actually means for the numbers they're looking at. This is a business decision as much as a technical one, and it's covered in more depth as its own topic elsewhere in this series.
No Regular Reconciliation Process
Even a well-designed integration will drift over time — small discrepancies that individually look immaterial but compound if nobody's checking. Companies that treat integration as a one-time setup rather than an ongoing process are the ones who discover a large, confusing variance months later instead of a small, easily traced one within days.
What to design around: A regular reconciliation cadence between inventory valuation and the general ledger — monthly at minimum, more frequently for high-volume operations — using dedicated reconciliation reporting rather than manual cross-checking.
Treating Integration as Purely an IT Project
The mistake underneath several of the above: integration decisions frequently get made by IT or an implementation partner without enough finance involvement, because costing methods and reconciliation cadence look like technical settings rather than financial policy decisions. They're both. A costing method choice has direct GAAP and tax implications; a reconciliation cadence is a financial control, not just a system configuration.
What to design around: Make sure finance leadership is genuinely involved in these decisions during setup, not just informed of them after the fact.
What Good Integration Actually Looks Like
None of this requires exotic technical solutions. It requires a costing method chosen deliberately with finance involved, a clear understanding of transaction timing, a regular reconciliation cadence, and consistent review of unapplied transactions before they accumulate. Companies that get this right don't have zero discrepancies — they have small, quickly traceable ones instead of quarterly surprises.