What Date Fields Are Available in NAV for Transfer Orders?

Microsoft Dynamics NAV — now evolved into Business Central — includes a dedicated transfer order workflow for moving inventory between locations. Within that workflow, several date fields control scheduling, posting, and logistics coordination. Understanding what each field does, and how they interact, helps warehouse managers, supply chain coordinators, and ERP administrators get accurate results from their inventory movements.

The Core Purpose of Date Fields in Transfer Orders

Transfer orders in NAV aren't just movement records — they're scheduling documents. The date fields embedded in them serve two distinct purposes: controlling when inventory is recognized at each location, and coordinating the physical logistics of the shipment. Mixing up these purposes is one of the most common sources of posting errors and inventory discrepancies.

The Main Date Fields You'll Find in NAV Transfer Orders

Shipment Date

The Shipment Date is the date on which goods are expected to leave the source (outbound) location. This field drives the outbound posting side of the transfer. When you post the shipment, NAV uses this date to record the inventory reduction at the shipping location.

It also interacts with the item's lead time calculation if you've set up shipping agents or transit times — NAV can use the shipment date to calculate when the goods are expected to arrive.

Receipt Date

The Receipt Date is the expected date that goods arrive at the destination (inbound) location. This is the date used when posting the receipt side of the transfer. It's what triggers the inventory increase at the receiving warehouse.

In setups where transit time is defined, NAV may calculate the receipt date automatically based on the shipment date plus the transit lead time. This auto-calculation depends on your shipping agent and shipping agent service configuration.

Posting Date

The Posting Date appears when you actually execute a posting — either the shipment or the receipt. This is the date that gets stamped on the resulting item ledger entries and value entries. It's the date that matters for financial reporting, inventory valuation, and period closing.

A key distinction: you can have a shipment date of one day and post the shipment on a different day. NAV will use the posting date entered at the time of posting for the ledger, not necessarily the document's planned shipment date.

Transfer Order Date (Document Date)

The Transfer Order Date — sometimes labeled as the document date depending on your NAV version — is the date the transfer order was created or initiated. This is primarily a reference date for document management and filtering. It doesn't directly control inventory or financial postings, but it's useful for tracking when planning decisions were made.

How These Fields Interact 📦

The planned dates (shipment and receipt) exist in the header of the transfer order and can be set well in advance. The posting dates are entered — or defaulted — at the moment of actual posting. This separation allows teams to plan ahead without committing to ledger entries until goods physically move.

Transit Location and the In-Between Date 🗓️

NAV's transfer order model routes inventory through a transit location — a virtual holding location that sits between the source and destination. When you post a shipment, inventory moves from the source to transit. When you post the receipt, it moves from transit to the destination.

Because of this two-step process, the shipment posting date and the receipt posting date can be different. This is by design. Goods can sit in transit for days or weeks, and NAV handles that gap cleanly through the transit location rather than creating a timing conflict in the ledger.

Variables That Affect How These Fields Behave

Not every NAV or Business Central setup works identically. Several configuration factors shape how date fields function in practice:

• Shipping agent setup: If you've configured shipping agents with service codes and transit times, NAV will calculate receipt dates automatically from the shipment date. Without this setup, dates must be entered manually.
• Inventory periods and posting date validation: If your environment uses closed inventory periods or posting date restrictions, NAV will reject postings with dates that fall outside allowed ranges — regardless of what's on the transfer order.
• Work date defaults: NAV's system work date is often used as the default posting date. Environments where users don't adjust this carefully can end up with postings on incorrect dates.
• Version differences: Older versions of NAV handle some of these fields slightly differently than Business Central. The field labels, default behaviors, and automation around transit time calculations have been refined across versions.
• Customizations and extensions: Many NAV implementations include custom fields, modified posting routines, or additional date validations added by implementation partners. What's standard in a vanilla NAV environment may behave differently in a heavily customized one.

Why Getting the Dates Right Matters

Incorrect date entries on transfer orders create problems that ripple outward. A receipt posting dated in a closed financial period can cause posting errors. A shipment date set too far in advance can distort demand planning reports. A mismatch between planned and actual posting dates can make inventory valuation reports unreliable if your organization uses average cost or FIFO costing methods, since those methods are sensitive to the timing of inventory movements.

The date fields in NAV transfer orders are precise tools — but their usefulness depends entirely on how consistently your team uses them, how your system is configured, and which version of NAV or Business Central your organization is running.