Why automatic cost adjustment locks up Business Central systems and causes locking
It seems logical to let cost adjustment run automatically in Business Central. After all, the system corrects cost prices as soon as new information becomes available. For example, an invoice that arrives later or a production variance that only becomes known afterwards. Yet in practice, automatic cost adjustment in Business Central or BC turns out to be one of the biggest causes of locking and performance issues. To understand why, we need to look at how the mechanism works technically. Why it reaches so deeply into the transaction chain.
How cost adjustment & locking arise in Business Central
Cost adjustment is a valuation process that recalculates the entire transaction chain of an item. When costs change, Business Central determines which transactions are affected by those changes. It does this by analysing three underlying data structures: the Item Ledger Entries, which record the physical movements of items; the Value Entries, which contain the financial values; and the Item Application Entries, which describe the relationships between purchase, sale, production and consumption. Together, these tables form a network of transactions that are connected over time. Cost adjustment traverses that network to determine where costs must be propagated.
The algorithm works iteratively. It first scans all value entries to determine which costs have not yet been fully propagated. It then follows the application entries to identify which transactions depend on each other. After that, it posts new value entries to pass costs on to related transactions. It converts provisional costs into final costs once all information is available and distributes production variances across the correct transactions. This process may require multiple rounds before all costs are fully processed, because new information can repeatedly affect earlier transactions.
Want to know more about these data structures? Read more about Item Ledger Entries, Value Entries and Item Application Entries.
Why cost adjustment and locking reinforce each other in BC
The reason cost adjustment sometimes needs to look back in time lies in the way Business Central finalises costs. A purchase may have been posted on January 1, while the sale of those goods took place on January 5. If the invoice only arrives on January 20 and contains a higher price, the system must still pass those higher costs on to inventory, sales, COGS and margin. That means historical entries must be reopened and corrected. This retroactive nature makes cost adjustment technically heavy.
When Automatic Cost Adjustment in BC is set to “Always”, Business Central tries to execute this entire valuation chain during the posting of a transaction; this will result in locking. During the posting of a sales, purchase or production transaction, Business Central starts a complex revaluation operation. Among other things. The system opens historical transactions, corrects the costs and writes new values. As it traverses this chain, it locks the involved tables. The system holds Item Ledger Entries while calculating corrections, blocks Value Entries while creating new values and locks Item Application Entries while following the transaction links. When Automatic Cost Posting is enabled, it also locks the general ledger tables while trying to post the corrected costs directly to the general ledger.
In SQL terms, this results in a combination of range locks, update locks, shared locks and intent locks on the key tables of Business Central. In an environment with many concurrent transactions, this creates a chain reaction of blocking, deadlocks and time‑outs. Warehouse processes stall, sales orders get stuck and users notice that the system responds slowly and unpredictably. The transactions themselves do not cause this delay, but the fact that Business Central executes cost adjustment in real time while users are simultaneously trying to process new postings.
The solution: configure job queue entries
When Business Central executes cost adjustment through a job queue, it almost completely eliminates the locking problem. The system processes the entire valuation chain sequentially, at a time when no one is posting transactions, so there is no contention between users and the revaluation process. SQL can efficiently use indexes and there is no competition between users and the valuation process. Cost posting can run immediately afterwards, without the general ledger being blocked by active transactions.
Microsoft emphasises in the documentation that cost adjustment is an intensive process that must be scheduled and is not intended to run in real time during transactions. The mechanism is designed as a batch process, not as part of the transaction routine. The technical best practice is therefore crystal clear: you disable automatic cost adjustment, you disable automatic cost posting, and you run both processes at night via job queues. By making that choice, Business Central remains fast and stable during office hours, while the system fully updates all financial values every night.
Conclusion
Cost adjustment is a valuation algorithm that depends on historical data, transaction chains, costing methods, variances and invoices. It is a complex process that only works reliably and with good performance when executed in batch. Running it inline inevitably leads to locking. Batch processing prevents that entirely and ensures that Business Central remains stable, even at high transaction volumes.
If you want to know more about this topic, click here. If you want to contact me, click here.
