Guides, glossaries and calculators to help you scope, cost and run an ERPNext implementation — from GST and e-invoicing setup to module-by-module walkthroughs.
Quick definitions of key terms
Expert insights and updates
Simple step-by-step resources
Easy explanations through videos.
Complete IRN flow in ERPNext (2026)
ERPNext HRMS for India's Labour Codes
ERPNext for Indian hospitals (NABH, ABDM, DPDP)
DPDP Act 2023 Compliance in ERPNext
One stock ledger behind every channel. A storefront that does not know what the warehouse holds oversells. A warehouse that does not know what the storefront sold ships late. And a finance team reconciling payouts by hand cannot tell you whether a discount code made money. All three are the same problem: stock and money living in two systems.
ERPNext connects to Shopify and WooCommerce through the Ecommerce Integrations app, with the underlying REST APIs and webhooks doing the work.
Through the Ecommerce Integrations app, which uses each platform's REST API and webhooks. Orders flow into ERPNext as sales orders or invoices with the customer created or matched, stock levels push back to the storefront from the ERPNext ledger, and payouts are imported so settlement can be reconciled against the orders inside them.
Order sync is the easy part and the part most integrations stop at. The value is in the three things after it.
Storefront inventory updated on a schedule rather than on movement means a window where two channels can sell the same unit. On a fast-moving SKU during a sale, that window is expensive and the customer finds out before you do.
A settlement lands weeks later, net of commission, payment gateway charges, shipping, returns and penalties, as a single figure. Matching it back to the orders inside it is manual, so most businesses book the net amount and stop asking questions.
A return has to restore inventory, reverse revenue, and carry the forward and reverse logistics cost. Handled loosely, stock drifts and the returned unit's true cost never lands anywhere, which quietly flatters your margin.
Coupon codes, storefront promotions and platform-funded discounts each affect contribution differently. If they arrive as one net line, you cannot tell a campaign that worked from one that bought revenue at a loss.
Scope is agreed per direction. Two-way sync sounds appealing and is not always what you want, so each flow is a deliberate choice.
New orders arrive by webhook as ERPNext sales orders or invoices, with the customer matched to an existing record or created, and line items mapped to your item master rather than to storefront titles.
Webhook-driven rather than polled, so the warehouse sees an order in seconds instead of at the next scheduled run.
Available quantity is calculated in ERPNext across every warehouse you nominate and pushed to the storefront on movement, so the channel reflects what you can actually ship.
Which warehouses count toward online availability is configurable — most businesses exclude damaged, quarantine and in-transit locations.
Payout files are imported and matched against the orders inside them, with commission, gateway charges, shipping and penalties posted to their own accounts rather than netted into revenue.
This is the piece that turns channel reporting from revenue into contribution. It is also the piece most integrations skip.
Refunds and cancellations flow back as credit notes with stock restored to the correct warehouse, and reverse logistics cost booked against the original order.
Restoring stock to a returns warehouse rather than to sellable inventory keeps the availability figure honest.
With deductions posted separately, margin reports by SKU, by channel and by campaign after commission, logistics, returns and discounts.
That number is the reason to integrate at all. Everything before it is plumbing.
Each row is a decision. A flow that is not needed is left off, because every active sync is something that can drift.
| Storefront object | ERPNext record | Direction | Notes |
|---|---|---|---|
| Order | Sales Order or Sales Invoice | Store → ERPNext | Webhook driven; document type depends on your fulfilment model |
| Customer | Customer + Contact + Address | Store → ERPNext | Matched on email or phone before a new record is created |
| Product & variant | Item + Item Variant | Either | Direction chosen deliberately — one side owns the master |
| Available quantity | Bin quantity across nominated warehouses | ERPNext → Store | Pushed on stock movement, not on a timer |
| Price & compare-at price | Item Price / Price List | ERPNext → Store | Optional; many brands price in the storefront instead |
| Fulfilment & tracking | Delivery Note | Either | Depends on whether you or the platform ships |
| Refund / cancellation | Credit Note + stock return | Store → ERPNext | Stock returns to a returns warehouse, not to sellable |
| Payout / settlement | Journal Entry + Payment Entry | Store → ERPNext | Deductions posted to their own accounts, not netted |
| Discount & coupon | Pricing Rule or discount account | Store → ERPNext | Kept separate so campaign contribution is measurable |
Order sync first, settlement last. The sequence matters because each stage depends on the previous one being trusted.
For products, prices and customers, one side owns the truth and the other follows. Deciding this before configuration prevents the sync loop where both systems keep overwriting each other.
Storefront products and variants are reconciled against your ERPNext item master, which usually surfaces a set of listings that were never proper items. Those get resolved here rather than at go-live.
API credentials and webhooks are configured, orders begin flowing into a sandbox instance, and availability push is tested against real stock movement including a deliberate oversell scenario.
Refund, cancellation and return handling is configured with the correct warehouses and accounts, then tested on real historical cases rather than clean ones.
An actual settlement file from a past period is imported and matched line by line, so the deduction accounts are proved against a payout you already know the answer to.
Timeline shown is indicative for a single storefront. Additional channels reuse the same structure but each has its own settlement format.
Several of these surprise people, so they are better read now than in week three.
Marketplace channels such as Amazon or quick commerce work on the same principles but have their own settlement structures and are scoped separately.
It reduces the window to seconds rather than removing the possibility. Availability is pushed on stock movement rather than on a schedule, and you choose which warehouses count toward online stock. A safety buffer on fast-moving SKUs is the usual complement to that.
Yes. Both connect to the same ERPNext instance and draw availability from the same stock ledger, which is the main argument for integrating at all. Each channel reports its own contribution while sharing one inventory truth.
The settlement file is imported and matched against the orders it covers, with commission, gateway charges, shipping and penalties posted to separate accounts. What you get is contribution per order and per SKU after deductions, rather than a net figure booked to revenue.
It depends on who creates products. Brands whose merchandising team works in the storefront usually let the store own descriptions and images while ERPNext owns cost, stock and tax. What matters is that one side owns each field, decided before configuration.
Webhook deliveries are retried by the platform and queued, so orders are not lost. Anything that still fails lands in an exception queue for review rather than disappearing, which is the same pattern we use for statutory integrations.
For Shopify it is the standard route and worth using rather than rebuilding. WooCommerce can also be connected through it. Where a business has heavily customised its store or needs behaviour the app does not cover, custom API work sits alongside rather than replacing it.
A short call about how many channels you run and whether you can currently say what any of them actually earns.
Shopify is a trademark of Shopify Inc. WooCommerce and WordPress are trademarks of Automattic Inc. ERPNext and Frappe are trademarks of Frappe Technologies Pvt. Ltd. These names are used here only to identify the software described. Finstein is not affiliated with or endorsed by Shopify Inc. or Automattic Inc.
