Item Tracking in Business Central, Explained

This is arguably the single most consequential, least obvious mechanism in Business Central warehousing — and the reason a scanning tool can look like it’s working perfectly right up until someone needs a recall trace it can’t produce.

Two different things wear the same name

Say the word “tracking” to most people and they picture a field: a lot number typed onto a document line, sitting there the same way a quantity or a unit price sits there. That picture is wrong, and it’s wrong in a way that has real consequences.

Business Central actually keeps two separate things that both look, from a distance, like “the lot number on this transaction.” What it looks like is a value sitting on a document or journal line — the same kind of thing as a quantity or a bin code, easy to assume you can just fill in and move on. What it actually is is a dedicated tracking layer, reached from the line but living on its own page, that has to independently account for the exact quantity on that line before Business Central considers the line’s tracking complete. It’s this layer — not a same-named field that might exist on the line — that the posting step actually reads.

Where tracking actually lives

Every inbound or outbound document line for an item that needs serial numbers, lot numbers, or package numbers gets its own Item Tracking Lines page, opened from that line. That page isn’t a convenience feature bolted on for data entry — it is the record. It shows the quantity on the document line, the quantity assigned to tracking numbers so far, and a running Undefined total that has to reach exactly zero before the line’s tracking is considered resolved. Business Central also calculates and displays availability information — how much of a given lot or serial is already spoken for by other documents — the moment the page opens, though it doesn’t keep that information live if inventory or other documents change while the page stays open; reopening or explicitly refreshing recalculates it.

Assigning a lot number here isn’t optional bookkeeping alongside the “real” transaction. For a tracked item, it’s what makes the transaction valid at all — the same way an unposted document can’t stay in that state forever, an outbound line with tracking still showing a non-zero Undefined quantity hasn’t actually specified what’s shipping.

When the document posts, the tracking that was assigned on that page is exactly what shows up on the resulting item ledger entries — never whatever might separately be sitting in a same-named field somewhere else on the line, if such a field even happens to be exposed on a given page. And once tracking numbers are assigned on the inbound side, Business Central carries them forward automatically to outbound warehouse activities — a pick or a shipment doesn’t ask a worker to re-type a lot number that’s already been assigned upstream; it already knows, because the system is tracking through its own dedicated layer end to end, not re-reading a loose value off a line at every step.

Transfer orders make this even more explicit: shipping and receiving on a transfer both use the same instance of the Item Tracking Lines page for that line, and the numbers that ship from one location have to arrive unchanged at the other — Business Central won’t let the tracking numbers be edited mid-transfer, precisely because the layer is meant to be one continuous, authoritative record of what moved, not something re-entered at each leg.

Two ways a number actually gets onto that layer

It’s worth being concrete about how tracking numbers get created in the first place, because both paths matter to different points in a business’s flow. On an inbound transaction, a number can be selected — chosen from lots or serials that already exist, the normal case when a vendor supplies its own lot numbers — or assigned — generated fresh from a predefined number series, or a customized series the business defines specifically for that receipt, the normal case when a business creates its own internal lot identity for stock a vendor didn’t already number. On an outbound transaction, the same two paths exist in reverse: select from existing tracked stock already on hand, or assign brand-new numbers at the point of sale, for items that aren’t tracked until they’re sold and shipped. Either way, the number that actually lands on the ledger is whatever was resolved through this page — never a value a worker separately typed somewhere else that happened to look similar.

Business Central also lets a lot or serial number carry its own information card — a short record for notes like quality-assurance status, with a Blocked flag that can exclude a specific number from any further transaction entirely. That’s a genuine safety mechanism, and it only works because tracking numbers are a real, addressable record rather than a string that happens to appear on a line: blocking a lot means blocking the actual tracking-layer record every transaction reads, not editing a value that a dozen different lines might independently be holding a stale copy of.

Why some scanning tools lose tracking without ever raising an error

This is the failure mode worth understanding before trusting any scan-driven tool with tracked inventory. Imagine a tool that captures a scanned lot number and writes it directly onto a transaction line’s own field, then posts the line. If that field isn’t the thing Business Central’s posting engine actually reads for tracking — if the genuine tracking layer, the Item Tracking Lines record, was never touched at all — the write still succeeds, and the post still succeeds. Nothing anywhere raises an exception, because as far as Business Central’s posting logic is concerned, the tracking layer for that line was simply never filled in. The transaction goes through. It just goes through untracked, silently.

Nobody sees an error at the moment it happens, because there isn’t one to see. The bug doesn’t announce itself when it occurs — it announces itself weeks or months later, when someone runs a trace on a specific lot and finds a gap in the chain, or when a recall needs to identify every downstream shipment a bad lot touched and the system can’t produce a complete list, because some step in that chain never actually carried real tracking.

The trap, stated as plainly as possible: a field that looks like “the tracking” and the field Business Central’s posting engine actually reads for tracking are not guaranteed to be the same field. Writing to the wrong one is a silent success, not a caught error — which is exactly what makes it dangerous. Tracking has to be attached the way the platform’s own posting step actually expects it, through the Item Tracking Lines mechanism itself, not just written onto a line and hoped for.

What this breaks downstream

Everything that depends on tracking being real depends on it being attached through the genuine layer, not a lookalike field:

• FEFO enforcement (see the previous article) needs a real expiration date attached to a real lot on a real tracking record — a pick can’t be sorted by an expiration date the system never actually captured in the first place.
• Recall and trace — finding every downstream transaction a specific lot or serial number touched — only works if every step in that chain genuinely carried tracking, not a value that happened to be typed somewhere and then silently dropped at the next posting.
• Availability and reservation checks, which tell a warehouse worker whether a specific lot is already spoken for by another order, depend on the exact same layer. A lot that was never really tracked can’t be reserved correctly, because there’s nothing genuine to reserve against.

None of these failures are loud. They show up as gaps — a trace that comes back incomplete, a reservation that doesn’t catch a conflict it should have caught — and by the time anyone notices, the transaction that caused the gap is long since posted and gone. There’s no error log entry pointing back at it, because from Business Central’s point of view, nothing ever went wrong.

The honest takeaway

None of this is a criticism of how Business Central is built. Keeping a dedicated, independently-verified tracking layer — one that has to account for every unit on a line before it’s considered resolved — rather than a loose field a user can type anything into, is exactly what makes trace and recall reliable when the mechanism is respected. It does mean that “does it let you type in a lot number” is the wrong question to ask any scanning tool that touches tracked inventory. The right question is whether it attaches tracking the way the platform’s own posting step actually expects, every time, for every operation that touches a tracked item — because the alternative fails in a way that looks, for weeks or months, exactly like success.

Where this goes next

See FEFO vs. FIFO, explained for the enforcement mechanism this tracking layer makes possible, and item tracking & FEFO in the user guide for how a scan-driven operation reaches this same layer in practice.

Key terms

New to the vocabulary? Item tracking lines, item ledger entry, lot number, serial number, and reservation are defined in the glossary.

Further reading — Microsoft Learn

Track Items with Serial, Lot, and Package Numbers — the Item Tracking Lines mechanism this article describes, including the Undefined-quantity rule and how numbers transfer to outbound activities. Design Details: Item Tracking — the underlying data model.