Inter-Branch Transfer Orders: Move Stock Between Sites Without Losing Track of It

It is Tuesday morning, and the branch manager in Fukuoka just told a customer that a replacement motor would arrive on Friday. The Osaka warehouse shows twelve units in stock. The Tokyo warehouse shows four. Nobody is sure which number is real, because last week three motors were put on a truck from Osaka to Fukuoka and nobody recorded who authorized the move, when they left, or whether they ever arrived. The customer is promised a date the company cannot honestly keep.

If you run stock across more than one location, you have lived some version of this scene. The stock exists. The records disagree. The people who moved it are not the people who need to answer for it. A core business system exists in large part to stop this from happening, and inter-branch transfer orders are one of the cleanest tools inside it for doing so.

Why moving stock between sites is harder than it looks

Most teams underestimate transfer work because it looks like a shipping problem. In practice it is an accountability problem. Every time goods leave one location and arrive at another, three records have to stay true at the same time: what left, what is in transit, and what landed. If any of those drifts, the next decision, whether to reorder, to quote a lead time, or to recall a lot, is made on bad information.

The pressure on this has grown sharply in Japan. The country's so-called 2024 Problem, the overtime cap placed on truck drivers, is shrinking how much cargo the road network can carry. Industry analysis estimates logistics delivery capacity was projected to fall about 14 percent by 2024, and could fall another 34 percent by 2030 if nothing changes. Roughly 80 percent of trucking firms reported labor shortages in a 2023 Tokyo Shoko Research survey. When every kilometer and every truckload costs more and is harder to book, you can no longer afford sloppy inter-site movements that force a second, emergency shipment to fix the first one.

A core business system with proper transfer orders lets a company move stock deliberately instead of improvising. Each transfer is a structured document with a number, a source, a destination, a date, and an owner, not a phone call and a prayer.

What an inter-branch transfer order actually is

Forget the jargon for a moment. A transfer order is simply a formal request to move a specific quantity of a specific product from one location to another, captured in a way the whole company can see. Think of it as the internal equivalent of a shipment document, except both ends belong to you.

In the Kikan System codebase, an inter-branch transfer order carries the things you would want if you had to defend the movement later. It has a server-generated document number (such as ITO20260001) so there is never a question of which transfer someone means. It names a source location and a destination location, and the system refuses to let them be the same place, which sounds obvious until you realize how many spreadsheet mistakes come from picking the wrong site from a long list. It records the person responsible for executing the move, the delivery method, the transfer date, and an optional expected arrival date.

Each order holds one or more line items. A line names the product, the quantity in its stocking unit, and how it is packaged. This last detail matters more than people expect: if you move three boxes versus three hundred pieces, the receiving warehouse handles the count very differently. Packaging unit and packaging quantity are first-class fields, not afterthoughts.

The lifecycle that keeps everyone honest

The part most teams get wrong is the workflow. Stock either left or it did not. A good transfer order reflects that reality with a defined lifecycle rather than a free-text status someone remembers to update.

In the system, every transfer order moves through a controlled set of states. It starts as a draft, where it can be edited freely while someone works out the quantities and the route. It is then confirmed, which locks in the intent and assigns responsibility. From there it is completed when the goods have actually moved, or cancelled if the plan changes. Once an order is completed or cancelled it cannot be edited or deleted, because a completed move is a historical fact, not a draft to be rewritten.

The transitions are enforced, not suggested. You cannot jump a draft straight to completed. You cannot cancel something already done. Cancelled orders can be reactivated back to draft or confirmed if a plan comes back to life. This sounds rigid until you have watched two warehouses argue over whether a transfer that supposedly shipped last month was real. Enforced states remove that argument.

Below the order, each line carries its own delivery progress: not delivered, partially delivered, or fully delivered. Crucially, the system computes these from the actual deliveries recorded against the order, not from a checkbox a tired clerk clicks. Once a line is partially or fully delivered, it is protected. You cannot quietly delete the record of stock that has already moved. That single rule does more for inventory accuracy than any quarterly cleanup.

A realistic scenario: a precision parts maker in Higashi-Osaka

Consider a precision parts manufacturer based in Higashi-Osaka, roughly seventy staff, with a second stockroom attached to its machining partner in Nagoya and a small distribution point serving Kyushu customers out of Fukuoka. The company turns over about 480 million yen a year. Its biggest recurring headache is not production. It is reconciliation.

Every month the accounting team spends close to three working days matching what the three locations say they hold against what the records claim should be there. Discrepancies of two to four percent per site are normal. A batch of raw aluminum that was supposed to sit in Nagoya turns up on the Fukuoka count. A finished component transferred to Kyushu for a customer deadline was never logged out of Higashi-Osaka. Each mismatch becomes an investigation, and each investigation becomes hours that nobody billed for.

When a company like this adopts a core business system and routes inter-site movement through transfer orders, the change is mechanical more than magical. The Nagoya stockroom requests aluminum from Higashi-Osaka. The request becomes transfer order ITO20260001, confirmed, with a named responsible person and an expected arrival date. When the truck is unloaded in Nagoya, the line moves to delivered. Routed through transfer orders, the move is then reflected in each location's stock count via the connected inventory-movement records: the source count falls when goods ship, and the destination count rises when they are received. There is no second spreadsheet, no end-of-month detective work, and no argument about whether the move happened.

Multiply that across a few hundred transfers a quarter and the three days of reconciliation shrink toward a few hours. That is the real return. It is not a headline number from a vendor slide deck. It is staff time recovered and customer promises kept.

Where the rules protect you from yourself

Two design choices in a transfer order system are easy to overlook until they save you.

The first is concurrency protection. When two people touch the same order, the system uses optimistic locking with a version number. If the Nagoya clerk and the Higashi-Osaka clerk both open transfer ITO202600014 and one saves first, the second save is rejected with a clear conflict rather than silently overwriting the first change. In a single-site business this rarely matters. Across three sites in different time zones, it is the difference between one version of the truth and three conflicting ones.

The second is the audit trail. Every order records who created it and who last updated it, with timestamps. For a Japanese company preparing for internal control review, this is not a nice-to-have. Being able to point at a specific person, a specific date, and a specific status transition is exactly what an auditor wants to see when they ask why stock moved the way it did. The status transitions themselves are attributable: every confirmation and completion records who made the change and when, so each stage of the move is traceable to a named person on a named date.

Honest limits: what transfer orders do not do automatically

A trustworthy vendor tells you what their product does not do, so here is the straight version.

Transfer orders move the record of stock. They do not, in this system, automatically post an accounting valuation entry to the general ledger when goods relocate between your own sites. Moving inventory between two warehouses you own is an internal movement, not a sale or a purchase, so it does not generate a journal entry the way a sales invoice or a purchase bill does. If your accounting policy requires a formal valuation transfer between cost centers, that journal entry is created manually today. Expecting automatic ledger posting here would be a mistake.

Transfer orders also do not by themselves optimize where stock should sit. They do not run demand forecasting, reorder-point calculations, or warehouse-slotting logic. They are the execution tool: they make the move you decided to make clean and traceable. The decision about what to move, and when, still belongs to a person reading the numbers. If a seller claims their transfer module will also decide your replenishment for you, ask to see it run on your data before you believe it.

Multi-currency is not part of this picture, which is correct for internal stock movement between your own sites in yen. If you ever need to value inter-site transfers across currency boundaries, that is a different conversation and a different configuration.

These limits are not weaknesses. They are the boundary between a feature that works reliably and a feature that overpromises. A core business system earns trust by doing exactly what it says, and by being honest about the rest.

Tying it to the rest of the operation

A transfer order is most valuable when it is not an island. Because it lives inside the same core business system as your sales orders, purchase orders, and inventory counts, the numbers stay consistent without manual sync. When a sales order in Fukuoka pulls from stock that is physically in Nagoya, the transfer request that follows uses the same product, the same unit, and the same location records. There is no second master file to drift out of date.

For companies that track lots, the same lot discipline that supports a recall follows the goods across the transfer. The product moved from Higashi-Osaka to Nagoya is the same product with the same lot identity, so when a customer question or a quality issue surfaces, you can trace the path without leaving the system. That continuity is what separates a real ERP from a collection of disconnected apps.

-> Related: Lot Management and Recalls

Frequently Asked Questions

Are we too small to need formal transfer orders?

If you operate a single location and never move stock, this is fair. The moment you run a second site, a partner warehouse, or even a consignment stockroom, informal transfers start costing you more than the discipline of writing them down. The break-even point is usually reached faster than people expect, and Kikan System lets a smaller team start on the free plan for up to 2 users, no credit card.

Will switching disrupt our current counts?

Adoption is the real risk, not the software. The cleanest path is to run transfer orders alongside your existing count process for one site pair first, reconcile both for a month, and expand once the team trusts the numbers. A vendor that pressures you to flip every site on day one is selling, not advising.

What is the return on a transfer-order module?

The direct return is recovered staff time and fewer emergency shipments. The indirect return is customer promises you can actually keep, which protects revenue you would otherwise lose to a competitor who can quote a real date. For a mid-sized maker running several sites, the recovered reconciliation days alone often pay for the change within the first quarter.

Can we migrate our existing transfer history?

Historical moves can usually be entered as completed orders with their original dates and responsible parties, so your audit trail does not start from zero. Plan this as a project, not a weekend, and prioritize accuracy of the open transfers over perfect reconstruction of years past.

Can a transfer be edited after it has been completed?

No. Once an order is completed or cancelled it cannot be edited or deleted, because a completed move is a historical fact rather than a draft to be rewritten. The status lifecycle is enforced, so you cannot jump a draft straight to completed, and each transition records who made the change and when.

Key takeaway: a core business system pays for its transfer-order module the day your three locations stop arguing about whose count is right, and start trusting one shared record of what moved where.

Start moving stock with one version of the truth

If your team is still reconciling branch counts by email and spreadsheet, that is the problem a core business system is built to solve. Kikan System includes inter-branch transfer orders with enforced status lifecycle, per-line delivery tracking, named responsibility, and a full who-did-what-when trail, so every move between your sites is deliberate and defensible.

You can try it without commitment. The free plan covers up to 2 users, no credit card required. Start at Get Started, or compare plans at Pricing.