Exact Cost Reversing in Business Central: What It Is and Where It Actually Lives

If you’ve ever compared two seemingly identical purchase-return scenarios in Business Central and gotten two different cost results, you’ve bumped into Exact Cost Reversing. It’s one of those costing concepts that’s simple in principle but easy to misplace when you go looking for it in the data model — I know, because I spent a while looking in the wrong tables before I found it. This post walks through what it is, why it matters, and exactly where BC stores the flag that controls it.

The short version

Exact Cost Reversing means: when you reverse a transaction (e.g. a purchase return, a sales return, or an item reclassification), Business Central applies the reversal back to the specific entry it came from, using that entry’s exact cost — instead of letting the standard costing method (FIFO, Average, etc.) pick whatever cost happens to be next in line.

When exact cost reversing does not apply, the reversal is costed the normal way: through the item’s costing method, which can pull a cost from a different entry than the one you’re actually reversing.

Seeing it in real data

Here are two purchase-return scenarios from the same environment, both using Average costing, that make the difference concrete.

Item 1004 — reversed with exact cost:

Entry No.	Document Type	Doc. No.	Quantity	Cost Amount (Actual)
822	Purchase Receipt	107233	1	10.00
823	Purchase Receipt	107234	1	20.00
824	Purchase Credit Memo	109004	-1	-10.00

The credit memo (entry 824) reverses receipt 822 for exactly -10.00 — the same cost the item came in at — even though a second receipt at a different cost (20.00) exists for the same item.

Item 1005 — reversed without exact cost:

Entry No.	Document Type	Doc. No.	Quantity	Cost Amount (Actual)
825	Purchase Receipt	107235	1	10.00
826	Purchase Receipt	107236	1	15.00
827	Purchase Credit Memo	109005	-1	-12.50

Here the credit memo (entry 827) doesn’t come back at -10.00. It comes back at -12.50 — the average of the two receipts (10.00 and 15.00) at the time of posting. The system didn’t reverse the specific receipt it was linked to; it costed the return the normal Average-cost way.

Same transaction type, same costing method, two different outcomes — purely because of whether exact cost reversing was in effect for that application.

Where the flag actually lives (and where it doesn’t)

This is the part that’s easy to get wrong, and I got it wrong a couple of times before pinning it down. The natural instinct is to go looking on the Item Ledger Entry or Value Entry table for a boolean called something like “Exact Cost Reversing.” It isn’t there. Neither table carries this flag.

The actual flag lives one layer down, on the record that links two entries together:

• Table: Item Application Entry (table 339), and its history counterpart Item Application Entry History
• Field: Cost Application (Boolean)

This makes sense once you think about what exact cost reversing actually is: it’s not a property of a single ledger entry, it’s a property of the link between an outbound entry and the specific inbound entry it applies to. Item Ledger Entry and Value Entry record what happened to an item; Item Application Entry records which entry was applied to which. Cost Application = Yes on that link is what tells the system “this application is exact — carry the cost across as-is,” rather than “this is just a quantity link — let the costing method decide.”

The field’s own tooltip in BC puts it plainly:

Specifies that the application entry should have the cost forwarded or simply included in an average cost calculation.

That’s the whole distinction in one sentence: Cost Application = Yes means the cost is forwarded from the applied-to entry (exact cost reversing); Cost Application = No means the entry’s cost is just included in an average cost calculation along with everything else in the period — which is exactly what happened to item 1005 above, where the credit memo picked up -12.50, the average of the two receipts, instead of the exact receipt cost.

You can confirm this by pulling the Item Application Entry record behind each example above:

Entry No.	Inbound Entry No.	Outbound Entry No.	Item No.	Cost Application
867	822	824	1004	Yes
870	825	827	1005	No

That single field is the entire difference between the two outcomes shown earlier.

Why the Application Worksheet won’t show it to you

If you go hunting for Cost Application from the Application Worksheet page using Page Inspection, you won’t find it — and that’s not a bug, it’s a scoping issue. The Application Worksheet (page 521) is built on Item Ledger Entry (table 32). Page Inspection only searches the fields of whatever table backs the page you’re on, so it will only ever show you ILE fields, no matter how you search.

The Application Worksheet lets you create and manage applications, but the resulting link — and the Cost Application boolean — is written to a separate table behind the scenes.

Where the setup-level control fits in

There’s a related but separate field worth knowing about: “Exact Cost Reversing Mandatory”, found on:

• Purchases & Payables Setup
• Sales & Receivables Setup

This is a policy toggle, not a record of what happened. When enabled, it forces users to always apply returns/reversals to a specific entry (rather than letting BC apply them automatically through the costing method) — which is what causes Cost Application = Yes to get set consistently going forward. Turning it on doesn’t retroactively change existing applications; it just changes how new ones get created.

Microsoft’s own documentation describes it the same way:

The Exact Cost Reversing Mandatory function helps ensure returned goods are valued at the same cost as when they were originally drawn from inventory, using a fixed application instead of following an average or first-in, first-out (FIFO) costing method. — Overview of tasks to set up purchasing, Microsoft Learn

How this plays into Average Cost specifically

Since item 1005 in the example above uses Average costing, it’s worth being precise about what “included in an average cost calculation” actually means for that method. Per Microsoft’s own design details on Average Cost, the average cost for a period is not simply “total cost in ÷ total quantity in” for every transaction in the period. Fixed-applied outbound transactions are deliberately pulled out of that calculation:

Subtracts the sum of the costs of any outbound transactions that were fixed-applied to receipts in the average cost period. These typically include purchase returns and negative outputs. — Design details - Average Cost, Microsoft Learn

In other words, when an outbound entry is fixed-applied — which is what Cost Application = Yes on the Item Application Entry represents — its cost is deliberately excluded from the pool used to calculate the period’s average. It’s carried across from its specific source entry instead. That’s the mechanism behind the item 1004 example: because the credit memo was fixed-applied to receipt 822, its -10.00 cost never entered the average cost pool for item 1004 at all — it just mirrored the receipt it reversed.

For item 1005, no fixed application existed, so the credit memo’s cost was left in the general pool and picked up the period’s average (12.50) instead of the specific receipt’s cost.

This is also why the terminology in Microsoft’s documentation and in the field name don’t quite match: the AL field is called Cost Application, but the concept it flags is consistently described in the Average Cost design documentation as fixed-applied or fixed application. If you’re reading through BC’s costing documentation and looking for “exact cost reversing” by name, “fixed-applied” is the term that will actually get you there.

Why this matters day to day

A few practical implications worth flagging to clients or teammates:

• Margin reporting can look inconsistent on returns if exact cost reversing isn’t mandatory — two visually identical credit memos can carry different costs depending on which entry they happened to apply to.
• Cost adjustment runs respect this link. The Adjust Cost – Item Entries batch job uses Cost Application (via keys like "Outbound Item Entry No.", "Item Ledger Entry No.", "Cost Application") to decide whether a reversal’s cost should move independently or stay pinned to its source entry.
• If you’re troubleshooting a costing discrepancy on a return, the fastest path is: find the Item Ledger Entry for the return → open its Applied Entries → check the Cost Application field on the link → check which inbound entry it points to and that entry’s cost. That tells you exactly why the number came out the way it did.

Summary

• There is no “Exact Cost Reversing” boolean on Item Ledger Entry or Value Entry.
• The actual flag is Cost Application on Item Application Entry (339) / Item Application Entry History — a property of the link between two entries, not of either entry alone.
• The setup-level “Exact Cost Reversing Mandatory” field (Purchases & Payables Setup / Sales & Receivables Setup) controls whether new applications default to exact cost or fall through to the item’s normal costing method.
• The Application Worksheet is sourced from Item Ledger Entry, so it won’t surface Cost Application in its field list — you need a page or table view sourced from Item Application Entry to see it directly.