September closes on a Friday. Gross margin comes in at 31.4%, the board pack goes out, and everyone moves on.
Three weeks later, the controller reruns the September P&L for a variance review and gets 30.9%. Nobody posted anything into September, and nobody reopened it. The difference traces back to October: a freight invoice assigned as an item charge to goods sold in September, and a supplier invoice priced above its receipt. Business Central forwarded both costs to the September sales, dated the adjustments to those sales, and posted them, because September was still open.
That’s a composite, but anyone who has closed a month in Business Central will recognize it. Nothing was broken. Business Central inventory costing keeps working after you post, and its adjustments land wherever the original entries live, which is often a month you thought was finished.
This piece covers how that happens, the four ways cost ripples backwards, the settings that decide where adjustments land, and what to test for each costing method. For the wider picture, start with our guide to Business Central test automation.
A Sale’s Cost Isn’t Final When You Post It
Business Central records every inventory transaction twice. An item ledger entry holds the quantity. Value entries hold the money, and one sale can collect several of them over weeks: an expected cost at shipment, the actual cost at invoicing, then adjustments as upstream costs change.
Those adjustments come from Adjust Cost – Item Entries, the batch job at the center of BC costing. Microsoft describes its purpose as forwarding cost changes “from cost sources to cost recipients, according to an item’s costing method”. The everyday case: an item can be invoiced to a customer before its purchase is invoiced, and cost adjustment later updates the cost of goods sold on that historic sale to match what the purchase actually cost.
For month-end, the detail that matters is the posting date. According to Microsoft’s design notes on cost adjustment, adjustment entries take the posting date of the entry they adjust. Only when that date falls in a closed accounting or inventory period, or before the Allow Posting from date, does Business Central move them to the first date of the next open period. If inventory periods and allowed posting dates are both set, the later date wins.
In Business Central, a sale’s cost isn’t final when you post it. It’s final when nothing upstream can change any more.
So the testing question isn’t only “is the cost right?” It’s also “which month did the correction land in, and did anyone expect it there?”
Four Ways Cost Ripples Backwards
Most surprise adjustments come from four sources. Each is normal business, which is exactly why they’re easy to miss.
| Trigger | What happens | Whose numbers move |
| Purchase invoice differs from the receipt | The receipt posted at expected cost and the invoice posts the actual cost. Sales already invoiced from that receipt are adjusted to match. | COGS on the earlier sales |
| Item charges posted later | Freight, duty or handling assigned to a receipt after the goods were sold. Microsoft’s own example: a sale on 15 January, a 2.00 item charge on 10 February, and the January sale adjusted by −2.00. | COGS on the original sale, dated to that sale |
| Backdated postings under average cost | An inbound entry dated inside an earlier average cost period changes that period’s average, so every outbound entry in it is recalculated. Microsoft’s example takes two sales from −15.00 to −17.00 each. | Every sale in that period |
| Negative inventory | A sale posted before stock arrives stays open until a receipt is posted for it to apply to. Its cost is provisional until then, and the open entry stops the inventory period from closing. | The sale, once stock arrives |
None of these raises an error. With Automatic Cost Adjustment at its default of Always, the adjustment happens during the posting that triggered it. And Business Central doesn’t log adjustments triggered by item posting, only batch runs, so there’s often no record anyone looks at.
The Settings That Decide Where Adjustments Land
In Business Central inventory costing, the same transactions produce different month-end numbers depending on five settings. Most companies set them once during implementation and never test them again.
| Setting | What it controls | What to test |
| Automatic Cost Adjustment | Whether posting triggers adjustment, and how far back from the work date: Never, Day, Week, Month, Quarter, Year or Always (the default). | A late cost inside and outside your window. Outside it, nothing adjusts until the batch job runs. |
| Automatic Cost Posting | Whether value entries post to the G/L as they’re created. It’s on by default; when it’s off, the G/L waits for Post Inventory Cost to G/L. | Inventory and G/L agree after each run, not only at month-end. |
| Expected Cost Posting to G/L | Whether received-not-invoiced and shipped-not-invoiced costs post to interim accounts. | Interim accounts clear to zero once the invoice posts. |
| Allow Posting From and inventory periods | Which dates adjustments can use. Entries that would land in a closed month move to the first open date. | Run the same scenario with last month open, then closed, and assert which month each adjustment lands in. |
| Average Cost Period and Calc. Type | Day, Week, Month or Accounting Period; per item, or per item, location and variant. Only one of each applies in a fiscal year. | Period boundaries and multi-location items. Microsoft recommends caution, and a word with your auditor, before changing either. |
The fourth row is the real decision, and it’s a trade-off rather than a right answer. Leave last month open and adjustments restate it. Close it, and this month absorbs a cost that belongs to last month. Both are defensible. Not knowing which one your configuration does isn’t, so test both and write the answer down.
BC Costing Method Testing: What to Assert for Each Method
Business Central supports five costing methods: FIFO, LIFO, Specific, Average and Standard. You can’t change an item’s costing method once it has item ledger entries, so the method in your item templates at go-live tends to stay for the item’s whole life. That’s a reason to test it before go-live, not after.
FIFO (and LIFO)
Cost follows quantity application: each outbound entry applies to a specific inbound entry, and adjustment forwards cost along that link.
- Assert the application, not just the cost. Check the item application entries: did the sale apply to the receipt you expected?
- Change an inbound cost after the sale with an item charge or a different invoice price, and assert the adjustment reaches the right outbound entries, and only those.
- Returns. A sales return fixed-applied to the original sale should reverse that sale’s exact cost.
Average
Average cost is a periodic weighted average. The Average Cost Period setting defines the periods, and each value entry’s valuation date decides which period it belongs to.
- Backdated inbound entries. Post a receipt dated inside an earlier period and assert every outbound entry in that period is recalculated.
- Period boundaries. A receipt on the last day of one period and a sale on the first day of the next: assert they average separately.
- Location and variant. Calculated per item, location and variant, the same item can carry a different cost in each warehouse. Assert each one.
- Nothing left pending. After adjustment, the Inventory Cost Adjustment page should show no items still waiting for adjustment.
Standard
Standard-cost items sell at standard, so late costs don’t move COGS the way they do under FIFO or average. They move variance instead. Microsoft’s formula is simply actual cost minus standard cost, and the standard is fixed at the moment you invoice the receipt.
- Late item charges. Post one after the purchase invoice and assert the purchase variance updates, not COGS.
- Standard cost changes. Revalue to a new standard and assert inventory value changes while variance doesn’t, because revaluation only changes inventory value.
- Variance accounts. Assert Purchase Variance (and the production variance accounts, if you manufacture) against amounts you worked out in advance.
Specific
Every application is fixed, usually through serial or lot numbers. Assert that each sale took the cost of the exact unit it shipped, and that a return brings that same cost back.
A Test Plan for Adjust Cost – Item Entries
Tests that catch costing problems look less like UI scripts and more like small accounting exercises: known transactions, a known order, a known answer. Six steps cover most of it.
| # | Step | What to do | What to assert |
| 1 | Seed | A fresh item per scenario, with known costs and no history. Reused items carry old applications that muddy the answer. | Starting quantity, value and unit cost |
| 2 | Post in the awkward order | Sell before the purchase invoice, post an item charge next month, backdate a receipt, let stock go negative. | Expected cost on receipts; open outbound entries where stock went negative |
| 3 | Adjust | Let automatic adjustment run, or run Adjust Cost – Item Entries yourself. | Each adjustment value entry: amount, posting date (which month) and valuation date |
| 4 | Post to the G/L | Automatic cost posting, or the Post Invt. Cost to G/L – Test report followed by Post Inventory Cost to G/L. | No skipped entries; interim accounts at zero after invoicing |
| 5 | Reconcile | Open Inventory – G/L Reconciliation and choose Show Matrix. | The Difference column is zero for every inventory account |
| 6 | Close | Run the Close Inventory Period – Test report, then close the period. | No open outbound entries or unadjusted items block the close |
Then run the plan again with last month closed, so you know what the same transactions do on the other side of the period boundary. Seeded scenarios are as much a data problem as a testing one, and our piece on test data management for AI agents covers keeping that data clean.
Turn on the observability Business Central now offers, too. Since the 2024 release wave 1, Inventory Setup has a Cost Adjustment Logging field (Disabled, Errors Only or All), and the Inventory Cost Adjustment page shows each item’s adjustment status, item batches, a log per run with the cost differences it produced, and a Costing Issues Detection report. The 2025 release wave 1 added notifications for suboptimal settings and data discrepancies, and item-by-item adjustment that saves progress as it goes. None of it replaces a test, but it tells you when to run one.
When to Rerun Your Costing Tests
Costing tests aren’t a go-live activity. Rerun them whenever something that touches cost changes:
- Business Central updates. Microsoft reworked cost adjustment in both the 2024 and 2025 first release waves, and monthly updates can touch posting code. Costing scenarios belong in the regression set described in our guide to Business Central update testing.
- Extensions. Apps that hook into posting can change what lands in value entries. Our piece on Business Central extensions testing covers how to catch that.
- Setup changes. Any change to the five settings above, new locations or variants under per-location average cost, and new item templates.
- More invoices, posted faster. BC’s Payables Agent drafts purchase invoices from emailed PDFs and proposes purchase order matches. It doesn’t post them; a person does. But every invoice posted at a price that differs from its receipt sets off the first ripple in the table above, so invoice automation and costing tests belong together. Our BC Payables Agent testing piece covers the agent’s side.
Where Sofy helps
Sofy’s Dynamics 365 test agents cover Business Central directly: the product page says they validate financials, purchasing, inventory, sales orders and postings. That’s exactly the span a costing scenario crosses. One costing test buys, receives, sells, invoices and posts, and the answer is only right if every step is.
The page also says the agents adapt automatically on every release wave, with no re-recording or regression rework, and run from Azure DevOps pipeline triggers. For costing, that means the scenarios above can run on every update and every build, not once a quarter when someone remembers. According to the page, environment setup for most D365 tenants takes less than a business day, and an initial suite typically takes one to two weeks.
SEE IT ON YOUR MONTH-END
Watch Sofy’s agents run purchasing, inventory, sales and posting scenarios in your own Business Central environment.
What Still Needs a Human
Tests can prove where adjustments land. They can’t decide where they should land. Whether to keep last month open, which costing method suits an item, and whether a restated margin is material enough to disclose are judgements for your controller and auditor. If inventory valuation is one of your key controls, our SOX testing checklist for AI agents in ERP covers the evidence side.
And when a test catches a surprise, someone still has to find out why: a mis-assigned item charge, a backdated receipt, a stock count that went negative. Testing just means you find out in a sandbox, with time to think, rather than in the board pack.
Frequently Asked Questions
What does Adjust Cost – Item Entries do in Business Central?
It forwards cost changes from where they arise, such as a purchase invoice or an item charge, to the entries that used that cost, such as sales and consumption. It creates adjustment value entries so COGS and inventory value match what items actually cost. It runs as a batch job, or automatically during posting if Automatic Cost Adjustment is switched on.
Why did last month’s COGS change in Business Central?
Because adjustment entries take the posting date of the entry they adjust. If a late purchase invoice, item charge or backdated receipt affects an item sold last month, and last month is still open, the adjustment posts into last month. If that period is closed, it moves to the first date of the next open period instead.
Should Automatic Cost Adjustment be set to Always?
Always is the default and keeps costs current, at some cost to posting performance. Shorter windows, from Day to Year, adjust only postings within that range of the work date, and anything older waits for the batch job. Whichever you choose, schedule Adjust Cost – Item Entries and test what your setting does to period-end numbers.
How do you test Business Central costing methods?
Build a small scenario per method with known costs, post the transactions in an awkward order (a sale before the purchase invoice, a late item charge, a backdated receipt), run cost adjustment and assert the value entries: amounts, posting dates and valuation dates. Then confirm Inventory – G/L Reconciliation shows no difference.
How do you reconcile inventory with the general ledger in Business Central?
Run Adjust Cost – Item Entries, check the Post Invt. Cost to G/L – Test report, post inventory cost to the G/L, then open Inventory – G/L Reconciliation and choose Show Matrix. Investigate any non-zero Difference before you close the period.
Can you change an item’s costing method in Business Central?
Not once the item has item ledger entries. That’s why the costing method in your item templates deserves a test before go-live: the choice usually stays with the item for life.
The Bottom Line
Business Central inventory costing is a process, not a posting. Every late invoice, item charge and backdated receipt sends cost back through entries posted weeks ago, and your settings decide when it lands and in which month.
Test it the way an accountant would: known transactions, posted in an awkward order, with the answer worked out in advance. Then assert the adjustment entries, the month they landed in and a zero difference on reconciliation, every time the system around them changes.