How ERPNext handles ERPNext inter-warehouse transfers and goods in transit
In ERPNext, a two-step inter-warehouse transfer separates the moment stock leaves the source warehouse from the moment it arrives at the destination. The sender creates a Material Transfer stock entry that moves items out of the source warehouse into a transit warehouse, and the receiving branch later books the arrival from that transit warehouse into its own stock. Until the receipt is booked, the quantity sits in transit as a measurable balance rather than disappearing from the books or appearing early at the destination. Teams need this flow when stock is on the road for days, when one branch replenishes another, or when a shipment arrives in parts and the receiving branch must record only what it actually counted.
The flow does not decide how transit stock is valued, which account holds it, or how the difference between dispatched and received quantities is written off. Those choices sit with your finance team and the perpetual inventory setup for each company, including the accounts assigned to the transit warehouse. Confirm with your accountant which account carries in-transit value before the first transfer is posted, and confirm how your chosen valuation method treats transfers between warehouses in your ERPNext version. Freight and duties added to the moved goods are a separate decision covered by landed cost handling, not by the transfer itself.
Before go-live, run a test transfer with a partial receipt and check three things: the in-transit balance by item, the stock ledger entries on both warehouses, and the value of the transit warehouse after the receipt is booked. Decide who may create, receive and close transfers, since those permissions control whether a branch can accept stock it did not count. Ask your implementation partner to confirm how your ERPNext release handles short receipts and any transfers still open at period end, using the release notes for the version you run.
What the send and receive steps record in ERPNext
The sending entry is what starts the movement, and it should be read as two stock ledger effects recorded in one voucher. A Material Transfer Stock Entry reduces the item quantity in the source warehouse and increases it in the transit warehouse you name as the target, at the valuation rate the source warehouse holds. Nothing reaches the receiving branch yet, so the value stays on the balance sheet in the transit location. Before go-live, confirm in the documentation for your version how the Stock Entry handles the transit option (the field is labeled *Add to Transit* in recent releases, but check the exact label and its behavior), and confirm which warehouse record you will designate as transit, since that record drives every later report.
The receiving entry closes the movement at the target. It draws the received quantity out of the transit warehouse and books it into the destination warehouse, so the transit balance falls and the branch balance rises by the same quantity. The point to plan for is the partial receipt. If the branch receives fewer units than were sent, the difference remains in transit until someone resolves it, whether by receiving later, returning stock, or writing it off through a documented adjustment. Confirm in your version whether the receiving document must reference the originating Stock Entry, and whether it can receive a partial quantity against a single send, because your receiving procedure depends on both answers.
In-transit quantity is read from the stock reports, not from a separate ledger. Filter the *Stock Balance* report to the transit warehouse to see what is currently in transit by item, and use the *Stock Ledger* report on the same filter to trace each send and receive voucher that made up that balance. Run this check at every period close, because a transit balance that never returns to zero usually means a receipt was missed or a partial shipment was never closed out. Confirm the exact report names and available filters in your version's documentation, and agree a rule with the operations team for who clears transit lines and how long a line may stay open.
Which transfer setup fits which branch network
A single transit warehouse per company receives all stock leaving any branch and releases it to whichever branch is the destination. This keeps the setup small: one warehouse, one set of accounts, and one place to look for everything in motion. It suits a company with a handful of branches, a modest transfer volume, and a finance team that wants one in-transit balance per legal entity.
- Simple setup: one transit warehouse per company means fewer warehouse masters and fewer account mappings to maintain.
- Single in-transit balance: the transit stock report shows all goods moving between branches in one place.
- Reporting trade-off: the transit balance cannot be split by branch pair without filtering on source and target, so per-route analysis depends on report filters and discipline in the transfer documents.
- Growth limit: as the branch count rises, one warehouse can hold stock for many unrelated routes, which makes reconciliation harder to read.
- Shared exposure: a stuck transfer on one route appears inside the same balance as healthy transfers on others.
Confirm with your finance team which account the transit warehouse maps to and how that account is reported at period close before you adopt this model.
Here each pair of branches that regularly moves stock gets its own transit warehouse. Goods from branch A to branch B pass through a dedicated transit location, and that location holds only that route's stock. This structure fits networks where a few routes carry most of the volume, or where each route has a different owner, carrier or accounting treatment.
- Route-level visibility: each transit warehouse balance shows exactly what is in transit on one route at any time.
- Clear ownership: a transfer that stalls can be assigned to the team responsible for that route.
- Setup cost: every new branch pair adds a warehouse master, and the number of pairs grows quickly with the branch count.
- Maintenance burden: new routes, closed branches and renamed warehouses all require changes to transit masters and any account mappings tied to them.
- Ask for a route inventory: list the pairs that actually move stock before you commit, since many theoretical pairs may never carry a transfer.
Illustrative example: a company with five branches and four frequent routes would maintain four transit warehouses rather than one per branch. Confirm the account mapping for each transit warehouse with finance before go-live.
A direct transfer moves stock from source to target warehouse in one document, with the receiving branch's stock increasing at the same time the sending branch's stock decreases. There is no transit balance and no separate receipt step. This fits branches that share a building or a short internal route, where goods arrive within the same working period and nobody needs to track them in motion.
- Fewest documents: one transfer record replaces the send and receive pair, which reduces daily workload.
- No transit balance: there is nothing to reconcile at period end for goods in motion.
- Less evidence of receipt: the system records the movement but not a separate confirmation that the receiving branch counted the goods.
- Weak fit for long or unreliable routes: partial deliveries, damage and delays cannot be recorded against an in-transit balance.
- Accounting timing: stock value moves immediately, so confirm with finance whether that timing matches how your branches report inventory.
If you later need goods in transit, moving from direct transfers to a two-step model changes stock postings and reports, so plan that change with finance and test it on a copy of your data.
Setting up transit transfers in ERPNext
This sequence turns ERPNext's two-step transfer flow into a tested process for your branches, so that stock leaving one site is visible in transit and lands correctly at the receiving site. The output is a configured transit setup and a signed-off test transfer that your team can repeat for other branch pairs.
Confirm the ERPNext version and warehouse tree
Your implementation lead records the ERPNext version you run and exports the current warehouse list with its parent-child structure, company assignment and any group warehouses. Confirm the version against the supported versions page before you build anything, because stock behavior changes between releases. Check the warehouse tree in the Warehouse list view, and confirm that every branch has its own stock warehouse under the right company. The step is done when you have a written list of branch warehouses, the company that owns each one, and the version in use.
Create transit warehouses for each branch pair
Create a transit warehouse for each sending and receiving relationship, or one shared transit warehouse if your accounting permits it, and mark it as a transit or group location in line with the ERPNext documentation for your version. Decide with your accountant which stock-in-transit account each transit warehouse maps to, since this drives the balance sheet. Use the Warehouse doctype and the menu paths in the ERPNext documentation for exact field names. The check is that each transit warehouse appears under the correct company and that its account is set before any transfer is posted.
Set item and UOM defaults for transferred stock
Review the items that will move between branches and confirm their stock unit of measure, default warehouse and any serial or batch tracking flags. Items tracked by serial number or batch need their bundles selected at the transfer stage, so flag them now rather than during a live transfer. Confirm that conversion factors for any purchase or secondary UOM are correct, because a mismatch shows up as a quantity error at receipt. The check is a small sample of items, each reviewed in the Item form, with no unexpected defaults pointing at the wrong warehouse.
Run a test transfer across one branch pair
Create a Stock Entry of type Material Transfer from the sending branch warehouse to the transit warehouse using two or three test items, then submit it. Repeat the transfer step from transit to the receiving branch in a second Stock Entry, leaving the first one in place for the moment, or use the two-step transfer process your version documents. Use a test company or a non-production site if you can, since ERPNext's Frappe Cloud public shared benches and some hosting options limit what you can change. The check is that both entries submit without errors and that quantities match the sending document.
Verify the stock ledger and in-transit balance
Open the Stock Ledger report and the Stock Balance report for the sending warehouse, the transit warehouse and the receiving warehouse, filtered to the test items. Confirm that the sending warehouse decreases, the transit warehouse holds the quantity while goods are moving, and the receiving warehouse increases once the receipt is posted. Then check the General Ledger for the stock-in-transit account, because a balance that does not net to zero after receipt signals a mapping problem. The check is that quantities and values balance across all three warehouses and the ledger entries match the test documents.
Test a partial receipt
Create a second transfer of a test item, then post a receipt at the receiving branch for less than the quantity shipped. Confirm how ERPNext handles the remainder: the difference should stay in the transit warehouse until you resolve it, or you record a separate adjustment according to your agreed process. Test the receipt with a serialized or batch item too, since a partial receipt on tracked stock needs the matching bundle quantities. The check is that the transit balance equals the shipped quantity minus the received quantity, and that the open difference is visible in a report your team reviews.
Document the approved process and sign off
Write down the transit warehouse map, the accounts behind each one, the transfer and receipt steps you tested, and the rule for handling partial receipts and open differences. Have finance and operations review the test results against the stock and general ledger reports from the previous step. Keep the test entries with their references so the process can be repeated when a new branch is added. The step is done when finance and operations have both signed the written process, and the test results show zero unexplained difference in transit.
Handling partial receipts and stock that stays in transit
When the receiving branch books less than the quantity the sending branch dispatched, the difference does not disappear. In a two-step transfer, the unreceived balance stays in the transit warehouse as stock in transit until someone resolves it, so the first decision is to make sure every open transfer has a named owner. The receipt against the Stock Entry or Delivery Note at the receiving side records the quantity actually received, and the gap between dispatched and received quantities is what the team must investigate. Confirm in your own environment how your version displays these open balances in the stock ledger and stock balance reports, and agree a routine review of anything still sitting in the transit warehouse at period end.
Decide in advance who investigates a shortage and how it is closed. Typically the receiving branch confirms the physical count, the sending branch checks its dispatch records, and the logistics or finance owner decides whether the difference is a carrier loss, a packing error or damage. ERPNext does not make that policy for you. For damaged goods, agree whether they are written off through a Stock Reconciliation, returned to the supplier, or kept in a quarantine warehouse for a claim. Each route leaves a different trail, so document the approval step before go-live rather than after the first shortage. Write these rules down as operating procedure for your own organization, and have your finance and audit stakeholders review them.
The accounting effect of a shortage or write-off depends on how your company has configured its stock accounts, including whether the transit warehouse is linked to a stock-in-transit or similar account and how perpetual inventory is set up for the company. Ask your finance team and implementation partner to confirm which account receives the difference, which cost center or expense account is used for write-offs, and whether the same treatment applies across all branches and currencies. Test one partial receipt and one write-off end to end in a non-production site and reconcile the stock ledger and general ledger before relying on the process for live transfers.
Where transit transfers commonly go wrong
Most transfer problems in ERPNext appear at the edges: when goods leave the source, sit in transit, or arrive at the destination. Each risk below has a control you can design, test and assign before the first live transfer.
Stock stuck in transit
A Stock Entry that ships goods to a transit warehouse without a matching receipt leaves inventory that no branch counts as available or owns. Assign a named owner to each transit warehouse and run a daily report of open transfers older than your agreed receiving window. Check that every dispatch record carries the destination and the expected receiver, so a stalled shipment can be traced to a person.
Negative stock blocked at source
ERPNext blocks a transfer when the source warehouse does not hold enough stock on the posting date, so a receipt not yet posted or a backdated sale can stop a shipment. Decide whether negative stock is allowed for your items and confirm the setting in your stock settings before go-live. Check the stock balance at the source on the posting date of each planned transfer, not just today.
UOM and serial or batch mismatches
A transfer recorded in one unit of measure and received in another can post the wrong quantity, and serial or batch items received without matching identifiers fail or drift from the source record. Standardize the stock UOM for each item, and confirm that conversion factors match the supplier and branch practice. For serial and batch items, require the receiver to scan or enter the same identifiers that left the source.
Backdated entries changing valuation
A transfer or receipt posted with a date earlier than existing entries can change the valuation of stock moved after that date. Confirm the valuation method for each item before transfers begin, and agree a rule for when backdated transfers are allowed. Run the stock reposting process after any backdated movement and compare valuation totals per warehouse before and after.
Multi-company access mistakes
When branches belong to different companies, a user with access to one company may create a transfer or receipt against another company's warehouse, which breaks inter-company accounting. Map which roles can post to transit warehouses for each company, and test a transfer under each role before go-live. Restrict warehouse permissions so receivers can only close transfers addressed to their own branch.
Transit stock in availability reports
If transit warehouses are not excluded from availability and stock reports, goods on the road appear as sellable stock at a branch that cannot ship them. Decide which reports should count transit inventory, and set warehouse flags or report filters to match that decision. Review stock availability on sales orders for a sample item during testing to confirm transit stock is not promised to customers.
Questions buyers ask about transfers in ERPNext
What does it cost to set up inter-warehouse transfers in ERPNext?
Cost depends on the written scope, not on a list price, so no figure is given here. Your quote should separate the one-time work (warehouse and item master review, transit warehouse design, transfer configuration, user training, and testing of send and receive flows) from any recurring retainer for support. The main drivers are the number of branches and warehouses, how many items carry serial or batch tracking, whether transfers must cross companies or currencies, and how much existing stock data must be cleaned before go-live. Ask each bidder to list which of these items they have priced and which they have excluded.
How long does a transfer rollout take across several branches?
Duration follows branch count and data readiness more than the transfer feature itself. A single transit warehouse and a few branches with clean item masters can be configured and tested quickly, while many branches with duplicate items, unmapped units of measure or open stock balances need a cleanup phase first. Ask for a timeline that shows the data cleanup, a pilot with one branch pair, the rollout sequence and the cutover window. Any figure you receive should come with the assumptions behind it, including how many branches are in the pilot and who signs off each stage.
What must our internal team provide before an implementation starts?
Your team needs to supply three inputs before any configuration begins:
- A warehouse master that lists every branch, store, distribution center and transit location, with the company each one belongs to.
- An item master with clean codes, units of measure, and flags for serial or batch tracking.
- Named process owners for receiving, dispatch, and stock control at each branch, who can decide how partial receipts and disputed quantities are handled.
You should also name a finance contact, because transfers affect stock valuation and the accounts that hold goods in transit.
Can our own team configure goods in transit in ERPNext without outside help?
Yes, a team with ERPNext administration skills can configure the basic two-step flow using the standard stock settings, warehouse setup and transfer documents. The harder parts are design decisions: how to structure the transit warehouse per company, how valuation and perpetual inventory accounts should treat goods in transit, how partial receipts and shortages are posted, and how to test these flows safely before live data is affected. Outside help is most useful for those design choices and for validating the setup against your accounting close. Whichever route you choose, record the decisions so the next administrator can follow them.
How do partial receipts and in-transit stock get tracked in ERPNext?
Engineers should expect each outgoing transfer to remain open against the transit warehouse until the receiving branch records what actually arrived. Partial receipts create a difference between the quantity sent and the quantity received, and that difference needs a defined owner and a resolution path, such as a follow-up receipt, a write-off, or a claim to a carrier. Before go-live, confirm in your own test environment how the transit balance, the stock ledger and the goods-in-transit account report each of these cases. Run a sample set of partial and rejected receipts through the full cycle.
What does ongoing maintenance of transfers look like after go-live?
Maintenance is mostly routine operations, not rebuilding. Plan for periodic review of open transit balances, checks that no transfers have been left in transit for longer than your policy allows, and reconciliation of transit accounts at each period close. Upgrades of ERPNext can change stock behavior, so each version move needs regression testing of the send and receive flows. You can run this in house or through a support retainer. Ask any partner what is covered in a retainer, how upgrades are tested, and how quickly they respond to incidents.
Does the work involve moving stock data between systems?
Only if your current branch stock sits in another system. If you migrate opening stock or open transfers from a legacy tool, the work includes mapping items and warehouses, loading balances with the Data Import tool in batches, and reconciling quantities and values before anyone posts a transfer. ERPNext's documentation advises importing only a few thousand records at a time, so large stock files need staged loads. Ask the partner how they reconcile migrated balances to your source system and who signs off the result.
Where to read the ERPNext documentation
Stock movement behavior in ERPNext changes between major versions, so the first thing to confirm is which version you run and whether it is still supported. The supported versions page lists the end-of-life dates for each line: version 14 reached end of life on January 31, 2026, version 15 is planned for support until the end of 2027, and version 16 until the end of 2029. Check that page before you read any guide, because a transfer screen described for one major version may not exist in another. Record the exact version on each site, including the minor release, since the minor release is what your staff will actually see. Support also depends on the plan: under Frappe's policy, warranty coverage requires a listed version and a matching Frappe Cloud support plan, so ask any hosting or implementation provider to confirm this in writing.
Use the frappe/erpnext repository as the reference for behavior. Its README describes the installation options, and its releases page lists minor releases for each supported major line, including v16.51.1 and v15.123.0, released in October 2026. Release notes for your exact minor version often record fixes to stock entries, transit handling and reports that a general guide does not mention. The code is licensed under GPL-3.0, so your technical team can read how the stock module creates and reverses ledger entries when stock is sent or received. Where the documentation and observed behavior disagree, the code and release notes for your version settle the question, and that is the evidence to bring to a support ticket or change request.
Before you rely on a transfer design, build a short checklist from the documentation for your version and test it on a staging site running the same release. Confirm which transfer document types you will use, whether a transit warehouse is created and how it appears in stock balances, how receipts and cancellations post, and what happens to a partial receipt. Ask your implementation partner to document which screens and reports you should see and which are hidden by role permissions. Keep a log of the version, the minor release and the test results so that later minor releases can be retested against the same cases. If your current version is approaching end of life, plan this test as part of the upgrade, not after it.
How DeployOpen scopes and delivers transit transfer work
DeployOpen plans, implements, customizes, tests and documents ERPNext inter-warehouse transfers and goods in transit inside your own infrastructure, whether that is your cloud account, your data center or an air-gapped network. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Map every branch, transit warehouse and stock account involved in moving goods between sites.
- Record which transfers use send and receive steps and which need direct movements for your process.
- Agree in writing how partial receipts, damaged goods and in-transit reporting will be handled.
- Confirm the ERPNext version and deployment method so the written scope matches your environment.
How we build
- Configure warehouses, the transit warehouse and item-level settings for each branch in a test site first.
- Set user roles and permissions so branch staff can send and receive only the stock they handle.
- Test full transfer cycles, including shortages, partial receipts and reversals, against documented expected results.
- Build any custom reports or scripts in a version-controlled app, with server scripts enabled only where your deployment allows them.
How we hand over
- Deliver written configuration records, a test log and step-by-step procedures for branch and warehouse staff.
- Walk your finance and stock teams through how transit balances post to accounts and how to reconcile them.
- Document the upgrade steps and the checks to repeat after each minor release of your ERPNext version.
- Confirm acceptance criteria with you before the engagement closes, as set out in the written scope.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live.
- Review transit balances and reporting changes when you add branches, items or companies.
- Plan upgrades on a tested copy of your environment before anything changes in production.
- Ask your team to confirm current support terms and retainer scope with DeployOpen during quoting.
