Why a simple transfer is not actually simple.
On the floor, a branch transfer feels obvious: pick the stock, load the truck, send it to the other branch, receive it. Done. From the books point of view, there are three distinct moments — dispatch, in-transit, receipt — and each needs to land in the right account on the right day. If you treat all three as one event, you lose the ability to answer the question "where is my stock right now?" when a customer service rep asks at 11 AM Tuesday.
The problem gets worse when transfers cross fiscal periods. If you dispatch on March 30 and receive on April 2, and you treat the whole thing as a single April event, March-end inventory at the source branch is overstated and the auditor will find it. The in-transit account exists to solve exactly this.
The three-step journal entry.
The clean accounting flow has three steps. On dispatch from source: Debit Inventory In-Transit, Credit Inventory at Source Branch. On receipt at destination: Debit Inventory at Destination Branch, Credit Inventory In-Transit. Inventory In-Transit is a regular asset account, sitting on the balance sheet between the two branch inventory accounts.
At any point in time, your in-transit balance equals the value of stock that has left a source branch but not yet been booked into a destination. If a truck takes two days, you should expect to see in-transit balances on most days. If your in-transit balance is zero or negative, your process is wrong somewhere — either dispatches are not being booked, or receipts are being booked before dispatches.
Costing the transfer correctly.
Which cost moves with the goods? This is where most ERPs trip up. Nonari uses SOURCE_FIFO costing on the source branch — the oldest cost layer leaves first. So if your Berlin warehouse holds 100 units bought at EUR 20.00 in January and 200 units bought at EUR 22.00 in February, and you transfer 150 to Hamburg, the first 100 leave at EUR 20.00 and the next 50 at EUR 22.00.
On the receiving side, those layers are blended into the destination branch WAC. Hamburg might have had 50 units at EUR 21.50 already; after receiving, its WAC becomes a blended figure across all units. This keeps source-branch FIFO discipline intact while keeping destination-branch costing simple. It also means an audit can trace any transfer back to the exact cost layer it consumed.
- Source branch: SOURCE_FIFO — oldest layer leaves first
- In-transit: carries the dispatched cost as a single line per dispatch
- Destination branch: blends incoming cost into existing WAC
- Audit trail: every transfer document links to the specific cost layers consumed
A worked example with real numbers.
Berlin warehouse holds two cost layers of an electric kettle: 80 units bought January 15 at EUR 12.00, and 60 units bought February 10 at EUR 12.80. Hamburg shop holds 20 units at a WAC of EUR 12.50. On March 5, dispatch 100 units from Berlin to Hamburg. Truck arrives March 7.
March 5 entry: Debit Inventory In-Transit EUR 1,216.00 (= 80 × 12.00 + 20 × 12.80). Credit Inventory Berlin EUR 1,216.00. Berlin WAC and on-hand both update. March 7 entry: Debit Inventory Hamburg EUR 1,216.00. Credit Inventory In-Transit EUR 1,216.00. Hamburg now holds 120 units at a new WAC of (20 × 12.50 + 1,216.00) / 120 = EUR 12.22.
What goes wrong without an in-transit account.
Some businesses still book transfers as a single instant event. The book debits destination and credits source on dispatch day. This works if the truck takes 30 minutes. It does not work for a cross-country run that takes three days, or for cross-city transfers that depend on a logistics provider.
The damage shows up in three places. Period-end inventory totals are wrong if a transfer straddles a month-end. Stock-on-hand at the destination shows phantom availability that nobody can find on the shelf. And reconciliation between physical count and book becomes impossible because the book moved instantly while the goods did not. Always use an in-transit account if any transfer takes more than a few hours.
Handling the truck that never arrived.
Sometimes goods leave a source and never get fully received — damage, theft in transit, short delivery, or just the box that fell off the truck. The in-transit account makes this clean. If 100 units were dispatched and only 95 received, you have 5 units worth of value sitting in in-transit with nowhere to land.
The journal: Debit Inventory Loss / Insurance Receivable, Credit Inventory In-Transit, for the missing value. Whether it goes to a loss account or a receivable depends on whether the loss is recoverable from a carrier. Either way, in-transit clears, the books are honest, and the document trail shows exactly which transfer the loss came from. Without an in-transit account, this kind of partial loss is almost impossible to investigate cleanly.
How nonari closes the loop end to end.
Nonari treats every branch transfer as a two-document workflow: a transfer dispatch and a transfer receipt. The dispatch automatically posts the source-side journal and consumes SOURCE_FIFO cost layers. The receipt automatically posts the destination-side journal and blends the cost into destination WAC. In-transit balances are visible on the dashboard at any time.
Receipts that do not match the dispatch — short, damaged, or rejected — get a variance line on the receipt document, which posts to Inventory Loss with a reason code. The full chain (source dispatch -> in-transit -> destination receipt + variance) is traceable from any side, so when a finance team member asks "what happened to those 5 missing kettles?" the answer takes one click.