The usual arrangement is that somebody opens the shop admin each morning, reads the overnight orders, and types them into ERPNext so the warehouse can pick them and accounts can invoice them. It works, in the sense that the orders do eventually arrive. It also means your ERP is always a few hours behind your shop, and that stock you have already sold is still showing as available to the next customer.
OrderWeave closes that gap. A customer checks out, your shop tells us, and the Sales Order is in ERPNext before anyone has opened a laptop.
What happens at checkout
The shop sends us the order the moment it is placed. We check the signature, so an order that did not come from your shop goes no further, then hand it to a worker that does the ERPNext side.
That worker resolves the customer first. A returning shopper is matched to the ERPNext customer record they already have, so their order history stays in one place and your sales reporting continues to mean something. A new one gets a customer record created for them. Then the Sales Order itself is written, with the lines, quantities and prices the customer actually checked out with.
From there it is an ordinary ERPNext document. Your team picks it, invoices it and ships it the way they always have, out of the system where the rest of the business already lives.
Changes and cancellations follow
Orders rarely sit still. A customer adds an item, changes an address, or cancels an hour later, and an integration that only handles the happy path leaves you reconciling the difference by hand.
Updates and cancellations come through the same route and are applied to the document that already exists, rather than creating a second one.
It respects how ERPNext documents work
This is the part that matters to anyone who has had an integration write to their ERP before.
ERPNext Sales Orders have a lifecycle. A draft is not a submitted document, a submitted document reserves stock, and a cancelled one can never be edited again. An integration that ignores that distinction will eventually do something expensive.
So ours does not force the document forward. If a web order is cancelled while its Sales Order is still a draft, we do not submit it in order to cancel it, because submitting would reserve stock and then release it, and leave you with an immutable cancelled document in your ledger for an order that never really existed. We record what happened as a comment on the order instead, and leave the decision to a person.
The same restraint applies to an order that has already been cancelled in ERPNext. Nothing is written over it. The comment explains what the shop said and when.
The result is an audit trail rather than a surprise. Anyone looking at a Sales Order can see what the storefront did to it and in what order, which is the first thing finance asks when two numbers disagree.
Where it works today
Order sync runs on WooCommerce. MedusaJS and Shopify currently send their catalogue updates out and do not yet bring orders back, and Shopify is the one we are building next.
Everything else about the catalogue, the prices, the stock and the photos, works on all three.
See pricing or talk to us about your order flow.
