Stock That Cannot Get Lost Between Branches
The truck leaves with 100 suits and 96 arrive. Without a system, those 4 vanish into an argument. In E-Khata every transfer is requested, approved, dispatched, and received as documents, goods in transit stay visible, and every shortage, rejection, and write-off lands on the right branch's books.
E-Khata Cloud moves stock between branches through a documented workflow: a Transfer Request that the sender approves, a Dispatch Note that moves goods into a visible In-Transit state, and a Goods Receipt at the destination that accepts, rejects, or reports units never arrived. Rejected units sit in quarantine until someone decides to release, return, or scrap them, and the whole story is valued at the sender's own cost on both sets of books.
Updated July 2026
A workflow bar that always knows the next step
Every transfer shows its journey as steps: Request Created, Approved, Dispatched, Received. Under it, one line says exactly what should happen next and one gold button does it: approve this request, dispatch goods, receive goods, or review quarantined stock. The sender approves and dispatches; only the destination can receive. A branch can never receive its own outbound shipment.
- Perspective-aware statuses: the receiver sees Incoming, receive it; the sender sees Dispatched, in transit.
- Drafting and posting are separately permissioned, so juniors prepare and seniors post.
- Every step records who did it and when, clickable through to the document.
Goods in transit are visible, not gone
Dispatching deducts the source warehouse and moves the goods into In-Transit, where they stay visible by product and by dispatch until the destination receives them. An In-Transit screen shows everything on the road with its value, and a reconciliation view checks that in-transit quantities and the in-transit money balance agree, so stranded stock cannot hide.
- Transfers past their expected arrival date raise a delayed-transfer alert automatically.
- The In-Transit money balance is a real ledger figure, not a guess.
- Cancelling a dispatch recalls the goods and reverses the entries, both sides or neither.
Receiving tells the truth: accepted, rejected, or never arrived
The destination records what actually happened to each line: how many arrived good, how many arrived damaged, expired, or wrong, and how many never arrived at all. Accepted units join the branch's sellable stock. Rejected units go to quarantine, on the books but not sellable. Units that never arrived are written off immediately and charged where they belong, with rejection reasons that must add up to the rejected count.
- Reasons are structured: damaged, expired, wrong item, or other, never a vague note.
- Shortage is its own count, separate from rejection, because it is a different problem.
- A serious discrepancy raises a critical notification the owner sees at once.
Quarantine ends in a decision: release, return, or scrap
Rejected units wait in quarantine until someone decides. Release puts them back into sellable stock because they turned out fine. Return raises a reverse transfer back to the sender. Scrap writes them off for good, and it is the only exit that touches profit and loss. Each action is its own permission, so the person who can receive goods is not automatically the person who can write them off.
- Scrap is deliberately senior-only by default: it destroys value permanently.
- Returned goods are re-inspected at the sender and cannot bounce in a loop.
- The banner counts what is still awaiting inspection until quarantine is empty.
Both branches' books stay right, automatically
Every quantity is valued at the sending branch's own recorded cost, never a number the receiver typed. Acceptance turns the sender's in-transit value into an amount the receiver owes. Rejections park value as stock pending inspection. Shortages and scrap become the sender's documented loss. All of it posts to proper Due From Branches and Due To Branches accounts, ready for settlement, with a reconciliation report proving both sides agree.
- System-posted entries carry full provenance: which document, which branch, which user triggered them.
- Charges between branches allocate oldest-first when settlements are paid.
- Nothing about transfer value is manual, so nothing about it can be argued.
One report that tells the whole story
Full history shows a transfer as a single chronological account: requested, approved, dispatched, received with the exact accepted, rejected, and never-arrived split, released, scrapped, returned, and every charge raised, with a running still-open balance. When the balance reaches zero the transfer is closed; until then the report names exactly where the outstanding units sit.
- Transfer Discrepancies screen totals not-received and rejected units across a period.
- Branch Stock Comparison shows every branch's stock side by side, including In-Transit.
- Documents number per business (like BF-DSP-2026-002), so two branches' papers never collide.
How a transfer runs
- Request and approveThe needing branch requests, the sending side approves. Nothing moves until someone answerable says yes.
- DispatchStock leaves the source warehouse into In-Transit, with transporter and vehicle on the dispatch note and labels printed if needed.
- Receive and inspectThe destination records accepted, rejected, and never-arrived counts. Rejected units hold in quarantine.
- Close the loopRelease, return, or scrap the quarantine, and the history report runs to a zero balance with both branches' books agreeing.
Who it is for
Frequently asked questions
Explore more of E-Khata
See how your business runs on E-Khata.
30-min Zoom or WhatsApp call. We'll walk you through E-Khata with examples that match your business type.
“I or my co-founder personally join every demo call.”
Or message us on WhatsApp: +92 300 1676722 (we reply within 1 hour).