Cycle Counting vs. Physical Inventory, Explained

Count everything once a year, or count the fast-movers every week and the slow-movers twice a year — these sound like two different strategies that would need two different tools. In Business Central they’re the same underlying mechanism with a schedule attached, and the more interesting distinction is a different one entirely: which journal a location’s warehouse setup routes a count through, and how much of a gap sits between “we counted this” and “the item ledger actually reflects it.”

Same mechanism, different reason to run it

A physical inventory count is the traditional full sweep — count everything on hand, typically once a year, to confirm the ledger matches reality before valuation. Cycle counting is the same act of counting, deliberately scoped down and run more often for a subset of items — perhaps because they’re high value, fast-moving, or simply prone to drift — by assigning each of them a counting period that defines how often it comes due. Neither is a separate posting mechanism from the other; cycle counting is physical inventory counting with a schedule, applied to a rolling subset of items instead of the whole warehouse at once.

Two journals, chosen by the location’s own warehouse setup

Which page actually performs a count depends entirely on whether the location uses directed put-away and pick, not on whether the count is a cycle count or a full physical inventory:

• Not using directed put-away and pick → the Physical Inventory Journal. A Calculate Inventory action computes the expected quantity per item (with filters for specific items, bins, locations, or dimensions), populating a Qty. (Calculated) field that starts out equal to a matching Qty. (Phys. Inventory) field. A counter only has to touch a line where the physical count actually differs from what’s calculated — lines that match need no entry at all.
• Using directed put-away and pick → the Warehouse Physical Inventory Journal, which creates one line per bin that matches the filter, because counting at this rung is inherently bin-scoped, not just item-scoped.

The same split applies to running a scheduled cycle count: Calculate Counting Period, run from whichever of the two journals matches the location’s setup, surfaces exactly the items currently due based on their assigned counting period — the mechanism doesn’t change, only which journal it’s run from.

Registering a count and posting a count are not the same step, at the directed rung

This is the distinction most worth understanding precisely, because it mirrors a pattern that shows up elsewhere in Business Central’s warehouse logic: at a directed location, finishing a count in the Warehouse Physical Inventory Journal means choosing Register, and registering does not post anything to the item ledger. It creates warehouse entries — a positive or negative quantity against the real bin that was counted, and a balancing entry of the opposite sign against the location’s adjustment bin, so the warehouse-level books stay internally consistent the instant the count is registered. Even where a count finds no discrepancy at all, Business Central still registers a zero-quantity entry for both the bin and the adjustment bin — the count genuinely happened and genuinely produced a record, even though nothing about the quantity changed.

None of that reaches the item, physical inventory, or value ledgers yet. A separate, explicit step — running Calculate Warehouse Adjustment from the Item Journal, filtered against the adjustment bin’s accumulated entries, then posting the resulting journal lines — is what actually carries the difference into the item ledger and closes the loop. Until that second step runs, the warehouse’s own bin-level records can be fully accurate and reconciled while the item ledger a finance user or a sales order actually reads from still reflects the pre-count quantity. That gap is a real, intentional window in the process, not a bug and not a sync delay to be alarmed by — but it is a gap worth knowing exists before assuming a registered count has already reached every downstream number that depends on inventory quantity.

The basic-rung Physical Inventory Journal doesn’t have this two-step split; posting it there both adjusts the item ledger and records the count in one action, because there’s no separate warehouse-entry layer underneath a location that isn’t using bins in the directed sense.

A count that finds nothing wrong is still a successful count

It’s worth being explicit about a case that’s easy to misjudge from outside the counting process: a physical inventory count that finds the calculated and actual quantities already match is not “nothing happened” — it’s the count doing exactly its job and confirming the ledger was already right. Posting a physical inventory journal is specifically described as adjusting inventory “to reflect the difference between the expected and the actual counted inventory,” and creating item ledger entries as part of that adjustment — which means where there is no difference, there is nothing for an item-ledger adjustment entry to record, even though a physical inventory ledger entry documenting that the count took place still exists and is exactly what a user checking the item’s Phys. Inventory Ledger Entries would expect to find. Anyone verifying that a count “did something” by looking exclusively for a new item ledger entry will misjudge a perfectly successful, zero-variance count as if it had failed to run at all — see what “posting” actually means in Business Central inventory for why the item ledger, while the right place to look for a genuine quantity change, isn’t the only place a legitimate inventory event gets recorded.

Synchronize before you count, at the directed rung

There’s a setup order worth respecting at directed locations specifically: item ledger and warehouse data should be synchronized before calculating expected inventory for a count, not after. Skip that step and whatever gets posted to the physical inventory journal and item ledger ends up being the count’s results tangled together with unrelated warehouse adjustments that had nothing to do with the count itself — an entirely avoidable source of a count that “doesn’t reconcile” for reasons that have nothing to do with anyone miscounting anything.

Don’t confuse a count correction with a reclassification

One adjacent tool worth distinguishing clearly: the item reclassification journal changes attributes on existing item ledger entries — dimensions, a sales campaign code, or, via transfer-style reclassification, the bin or location an entry is recorded against — without representing a physical quantity change at all. It’s the right tool for “this was recorded against the wrong dimension” or “this needs to move to a different bin on paper because that’s where it’s actually always been,” not for “we counted and found a real quantity discrepancy.” Reaching for a reclassification journal to fix what was actually a counting discrepancy — or the reverse — produces entries that are individually valid but describe the wrong kind of event.

Why the distinction is worth keeping straight

None of this changes how often a business should count anything — that’s a judgment call about item value, shrinkage risk, and how much confidence the business needs in its own numbers day to day. What’s worth keeping straight is that cycle counting and full physical inventory are the same underlying process at two different schedules, that which journal performs either one depends on the location’s warehouse configuration rather than on which of the two you’re doing, and that at a directed location specifically, “registered” and “reflected in the item ledger” are genuinely two different moments with a real, intentional gap between them.

Where this goes next

The general principle this article’s zero-variance case illustrates — that the item ledger is the right place to look for a quantity change, but not the only legitimate record of an inventory event — is covered in full in what “posting” actually means in Business Central inventory. For the adjustment bin that absorbs the balancing side of every registered count discrepancy, see bin setup and bin content, explained. For where counting sits relative to the rest of a directed location’s setup, see warehouse topology, explained.

Key terms

New to the vocabulary? Cycle count, Physical inventory, Warehouse Entry, and Item ledger entry are defined in the glossary.

Further reading — Microsoft Learn

Count, Adjust, and Reclassify Inventory — the full procedure for both journals, counting periods, and the warehouse-adjustment synchronization step described above.