Fixed Application in Business Central: The Mechanism Behind Exact Cost Reversing

In an earlier post I walked through the Cost Application boolean on the Item Application Entry table and how it drives exact cost reversing. That post answered where the flag lives. This one answers the question underneath it: what is Business Central actually doing when it sets that flag — and that mechanism has a name in Microsoft’s own documentation: fixed application.

What a fixed application is

Per Microsoft’s Design Details: Item Application page:

You make a fixed application when you specify that the cost of an inventory increase should apply to a specific inventory decrease, or vice versa. The fixed application affects the remaining quantities of the entries, but the fixed application also reverses the exact cost of the original entry that you are applying to, or from.

That’s the core idea in one paragraph: a fixed application is a deliberate, specific link between one entry and another — as opposed to letting Business Central’s normal costing method (FIFO, Average, Standard) decide which cost to pull. Making that link is what causes the exact cost to travel across, instead of a calculated cost.

How you actually create one

You don’t set Cost Application directly — it gets set automatically as a side effect of creating the link. Per the same Item Application design details page:

To make a fixed application, you use the Appl.-to Item Entry field or the Appl.-from Item Entry field in the document lines to specify the item ledger entry that you want the transaction line to apply to, or from.

So the fields a user actually touches are Appl.-to Item Entry (on an outbound line, pointing at the inbound entry it should apply to) and Appl.-from Item Entry (on an inbound line, pointing at the outbound entry it should apply from). Fill either one in, and BC creates a fixed, cost-carrying application rather than leaving the match to the costing method.

According to Microsoft’s documentation, a fixed application is made by the user when:

• Processing returns
• Posting corrections
• Undoing quantity postings
• Creating drop shipments

And it can be created either manually, by entering an entry number directly in the Appl.-from Item Entry field, or automatically by a function such as Get Posted Document Lines to Reverse — which is exactly the function behind a sales or purchase return order that pulls in the original shipment/receipt line for you.

Quantity application vs. cost application

The same page draws a distinction worth internalizing: Business Central always makes a quantity application for every inventory transaction — that’s just bookkeeping for remaining quantities. A cost application is different: it’s only created for inbound entries, alongside the quantity application, and it’s what actually governs cost forwarding. A fixed application is what turns a plain quantity link into a cost-carrying one.

This maps directly onto what we saw in the item 1004 / item 1005 example in the earlier post: both credit memos created a quantity application against their respective receipts (BC always does this), but only item 1004’s credit memo had a fixed application — which is why only it forwarded an exact cost instead of picking up the average.

Seeing it work: the exact-cost-reversal example

Rather than reach for a new scenario, this is the exact mechanism behind the item 1004 / item 1005 example from the earlier post — it’s worth walking through again here with fixed application specifically in view.

Item 1004 — a fixed application was created:

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

Behind the scenes, the credit memo (824) was posted with its Appl.-to Item Entry pointing at receipt 822. That’s the fixed application. It shows up as this Item Application Entry record:

Entry No.	Inbound Entry No.	Outbound Entry No.	Cost Application
867	822	824	Yes

Because the application is fixed, entry 824’s cost (-10.00) is an exact mirror of the receipt it’s reversing (10.00) — not the average of the two receipts on hand. No average, no FIFO layer lookup. That’s the mechanism, made visible.

Item 1005 — no fixed application was created:

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 (827) wasn’t posted against a specific Appl.-to Item Entry. BC still created a quantity application — every transaction gets one — but not a fixed one:

Entry No.	Inbound Entry No.	Outbound Entry No.	Cost Application
870	825	827	No

With no fixed application to force an exact cost, entry 827 was left to the item’s normal costing method (Average), and it picked up -12.50 — the average of the two receipts (10.00 and 15.00) — instead of mirroring either one exactly.

Same document type, same costing method, same item structure — the only difference is whether a fixed application was created at posting time, and that single decision is the entire reason the two credit memos landed on different costs.

Fixed applications can also correct a cost, not just reverse one

It’s worth noting that fixed application isn’t only for returns. Per Microsoft’s documentation, it’s also used defensively — to fix a posting mistake. If a purchase invoice is posted with the wrong direct unit cost, a purchase credit memo can be posted with a fixed application pointing back at that exact incorrect entry. Because the application is fixed, the credit memo’s cost matches the mistake exactly, cleanly zeroing out the wrong cost rather than smearing it across an average — the same mechanism at work in the item 1004 example above, just applied to error correction instead of a return.

Tying it back to what you’ll actually see in BC

Put together with the previous post, the full chain looks like this:

1. A user (or a function like Get Posted Document Lines to Reverse) fills in Appl.-to Item Entry or Appl.-from Item Entry on a document line.
2. Business Central creates a fixed application between the two entries.
3. That fixed application is what sets Cost Application = Yes on the resulting Item Application Entry record.
4. Because of that flag, the entry’s cost is forwarded exactly from its applied-to entry, and — for Average-costed items — it’s also excluded from the average cost pool for the period, per Design Details: Average Cost.
5. The setup field Exact Cost Reversing Mandatory, on Purchases & Payables Setup / Sales & Receivables Setup, is what makes step 1 happen automatically and consistently for returns, instead of relying on a user remembering to fill in the field.

Fixed application is the user-facing action; Cost Application is the database record of that action; exact cost reversing is the effect it has on the resulting cost. Three names, one mechanism.

References

• Microsoft Learn: Design Details: Item Application — Fixed Application