Why ERPNext for retailers starts with the store, not the ledger
A retailer running shops, a warehouse and online orders on separate tools usually discovers that the same product has three different stock counts and that store takings reach accounting only after someone reconciles spreadsheets. ERPNext can hold stock, point-of-sale sales and online orders in one system, so the record of what sold, where, and from which location exists before anyone opens the ledger. ERPNext is free and open source under GPL-3.0, and the Frappe Framework it is built on is MIT licensed, so the software cost of running the system is not the decision that needs the most scrutiny. The decision is how stores, warehouses and sales channels map onto warehouses, POS profiles and accounts.
For store managers, the change is that stock movements and till activity are recorded against the outlet where they happen, which makes shrinkage, transfers and stock counts a question they can answer themselves. Finance gets postings that arrive from the operational documents rather than from end-of-day summaries, so the questions to settle early are which income, tax and payment accounts each POS profile posts to and how cashier sessions are closed. Ecommerce teams need to know whether online orders reserve stock in the same warehouses the stores draw from. Confirm with your own team how each channel should share or split stock before configuring anything, because that choice shapes every report that follows.
Before committing to a design, ask a partner to walk through a worked example with your real product list, two stores, one warehouse and one online channel, and show which document created each stock and accounting entry. Confirm the POS, loyalty and marketplace behavior against the version you intend to run, since those features depend on configuration and on companion apps rather than on the core system alone. The rest of this page covers each part of that design in turn.
Which retail requirements shape the build
This table maps the main retail requirements to the ERPNext or Frappe capability that addresses each one, and to what that means for the build. Read each row as a question to answer before configuration starts, since several rows depend on whether a feature is available in your chosen version and hosting model.
| Requirement | Documented capability | What it means for the build |
|---|---|---|
| Per-outlet cash handling | POS and sales invoices in ERPNext, with outlet-level setup to be confirmed in your version | Confirm how POS profiles, cashier sessions and cash accounts map to each outlet before creating accounts or users |
| Stock across shops and warehouses | Multi-warehouse stock tracking in ERPNext stock module | Define one warehouse per shop and any central warehouse early, since transfers and valuation depend on this structure |
| Online and marketplace order intake | Order sync through ERPNext integrations, to be confirmed per connector | Map which orders create sales orders, which move stock, and which reach accounting, and confirm this per connector |
| Store sales in accounting | Sales invoices post to the general ledger in ERPNext | Decide whether daily store totals post as summarized invoices or itemized entries, and confirm with your accountant |
| Staff access by outlet | LDAP login with automatic mapping of LDAP groups to ERPNext roles at each login | Map directory groups to ERPNext roles per outlet, and test that a cashier cannot see other outlets' records |
| Bulk loading of product and customer data | Data Import tool for CSV or Excel, with child table support, documentation advises a few thousand records per import | Plan item and customer loads in batches and validate each batch before the next one |
| Custom checks or automation at checkout | Server Scripts are disabled by default from version 15 and need the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them | Confirm your hosting model before designing any custom rule, because it may need a custom app instead |
Which ERPNext modules and settings a retail build depends on
A retail build on ERPNext connects point of sale, stock, pricing, online order channels and accounting. Each card below names one setting that decides how those pieces fit together, and what to confirm against the ERPNext documentation for the version you run.
POS profiles per outlet
A POS Profile holds the defaults a till uses: company, warehouse, price list, currency, payment modes and the item groups it may sell. Creating one profile per outlet keeps each shop's stock source and pricing separate, and it is the first place a store's sales get tied to a warehouse. Confirm which fields the POS Profile exposes in your version and who is allowed to edit them.
Cashier sessions and shift closing
A POS Opening Entry and closing entry record who opened a till, the float counted in, and the totals expected at close. Reconciling those totals against payments taken is how a shop finds cash differences per shift. Decide who may open and close sessions, whether cashiers can overwrite the float, and how voided invoices are approved.
Warehouses and stock per shop
Each shop usually needs its own warehouse, with a separate store-room or back-of-house location where stock is held before it reaches the sales floor. Warehouse structure decides how transfers, stock counts and valuation are reported by outlet. Map every physical location to one warehouse before go-live, and confirm how negative stock is handled for each item.
Items, variants and price lists
Items, item variants for size and colour, item groups and price lists determine what a till can sell and at what price. Separate price lists per channel or region keep store prices, online prices and wholesale prices apart. Check how variant attributes are created, how barcodes are assigned, and which price list each POS profile and online channel uses.
Ecommerce integrations for Shopify and Amazon
The Ecommerce Integrations app is the connector to review when online orders must reach ERPNext. It decides which order statuses create sales orders, how product SKUs are matched to items, and which stock updates flow back to the storefront. Confirm the current supported connectors, sync frequency and what happens to returns and cancellations in your ERPNext version before you map stock locations.
Payment gateways and mode of payment
Each payment method a shop accepts needs a Mode of Payment mapped to a ledger account, and card or online gateways need their own gateway account. These mappings decide where cash, card and online receipts land in the books. Confirm how settlement fees and payouts from each provider are booked, because those amounts rarely match the sale value.
Accounting postings for store sales
Store sales can post to accounting as consolidated POS invoices or as individual invoices, and that choice changes how daily takings appear in the ledger. Stock movements post to valuation accounts, and cost of goods sold follows the valuation method you set. Agree the posting approach with your accountant, and confirm how returns, discounts and tax lines are recorded in your version.
How the build differs for single-store, multi-store and omnichannel retailers
A single shop with an online store usually needs one company, one warehouse for the shop floor and online orders, and one POS profile. The main design question is whether the webshop and the till share one stock ledger from day one, because splitting them later means reconciling item counts and reposting stock. Illustrative example: a boutique with one counter and a small catalog may run a single POS profile, one warehouse and a webshop connector, with item variants handled in the item master.
- POS profile: One profile covers the till, payment modes, default warehouse and price list. Confirm which payment modes your acquirer requires before configuring it.
- Stock locations: Decide whether online orders ship from the shop warehouse or a separate back-room warehouse, since that changes how returns are received.
- Item master: Simple catalogs can use standard items, while apparel or footwear with sizes and colors needs variant attributes set before any sales data is loaded.
- Webshop integration: Choose a connector that syncs orders, stock and item data in both directions, and ask the vendor which fields it does not sync.
- Data volume: Expect a modest daily order and sales count, so a single site sized for the back office is often enough. Confirm growth assumptions with your own sales history.
Check which connectors and payment gateways your store already uses, and whether the webshop platform is one that the ERPNext integrations documentation covers.
A chain with several outlets adds a warehouse per store, a POS profile per outlet and a central warehouse that replenishes them. The decisions shift to transfer rules, price lists per region, and how store sales post into one set of accounts. Cashier sessions and cash handling at each outlet must close into the same ledger without manual rekeying. Illustrative example: a chain of five outlets may run one company, five store warehouses, a central distribution warehouse and five POS profiles tied to one price list group.
- Warehouse tree: Model each outlet as a warehouse under a group that matches your reporting, and set the default warehouse on each POS profile.
- Replenishment: Decide whether stock moves by manual material transfer, by reorder levels or by a scheduled process, and test the transfer approval steps with store managers.
- Cashier sessions: Define how each shift opens and closes, who counts cash, and how over and short amounts post to the ledger.
- Accounting consolidation: Confirm whether store sales post daily summaries or individual invoices, since that affects reconciliation effort and audit trails.
- Data volume: Store counts multiply transactions, so ask the implementer how many sales lines per day the design assumes and how the database and reports will be sized.
Before quoting, ask which outlets need different tax treatment or price lists, and whether a central team will approve stock adjustments.
An omnichannel seller sells in stores, on its own site and on several marketplaces, so orders arrive from many sources and must reserve one shared stock pool. The build adds marketplace connectors, reservation rules, return routing and fee reconciliation. Integration effort is usually the largest part of the scope because each marketplace has its own order statuses, listing rules and settlement reports. Illustrative example: a brand selling through its own site, two marketplaces and retail stores may need a connector per channel, a shared stock pool, and a rule for which channel reserves units first.
- Stock allocation: Decide whether each channel gets a fixed quantity, a shared pool or a buffer, and document who changes these rules.
- Marketplace connectors: Confirm for each marketplace which order, return and settlement fields the connector syncs and which it leaves to manual handling.
- Fees and settlements: Plan how marketplace commissions and payouts post to accounting, since these often arrive as separate reports.
- Returns routing: Define where returned items from each channel are received, inspected and restocked, including items that cannot be resold.
- Data volume and rate limits: Marketplace APIs limit request rates, so ask how the integration handles bursts during sales events and how failed syncs are retried.
Before committing scope, check each marketplace's current API terms with the vendor, and confirm which channels your team can test end to end.
Most retailers sit between two situations, for example a chain that has started selling online. Use the number of outlets, the number of order sources and whether stock is shared across them as the first test. Once the situation is clear, the scope, integration list and data migration plan follow from it. Illustrative example: a single-store business that adds a second outlet and a marketplace listing has moved from the first tab to the third in effect, so its stock and order design should be revisited before the second outlet opens.
- Outlet count: Each new outlet adds a warehouse, a POS profile and cashier sessions to configure and test.
- Order sources: Each new channel adds a connector, a status mapping and a reconciliation routine.
- Shared stock: The more channels that draw from one stock pool, the more important reservation and transfer rules become.
- Ownership of decisions: Name who approves price lists, stock adjustments and return rules, since these decisions drive configuration.
- Growth path: Ask whether the design can add outlets and channels without rebuilding the item master and warehouse tree.
Ask your implementer to walk through the warehouse tree, POS profiles and connector list against your current and planned channels before agreeing on a fixed scope.
How a retail rollout runs from pilot store to all outlets
This sequence moves ERPNext from a verified set of master data and one pilot outlet to every store and warehouse, with each stage closed by a check the business signs off. It keeps store sales, stock and accounting reconciled before the rollout widens.
Confirm scope and inventory every outlet
The retailer and the implementation lead list every store, warehouse, online channel and marketplace account, along with the company and currency each one posts to. Finance confirms which outlets consolidate into which ledgers, and IT records the chosen hosting path, such as Frappe Cloud, Docker Compose or a bench install on servers you control, because it sets who patches, backs up and sizes the environment. The step closes with a signed scope list that names each outlet and its owner.
Build the item and price master
Merchandising and finance agree the item codes, variants, units of measure, tax templates and price lists before any transactions are loaded, because later corrections touch every document that uses them. Each price list is tied to the outlets or channels that use it. The implementation team checks a sample of items against the current shelf tickets and the online catalog. The step is complete when the master data has been reviewed by the buyer who owns it.
Import opening data in small batches
The team prepares the ERPNext Data Import templates for customers, suppliers, items, prices and opening stock, then loads them in batches of a few thousand records, as the import documentation advises. Each batch is checked against the source counts and stock valuation before the next one runs. Errors are fixed in the source file and re-imported so the audit trail stays clean. The step closes when record counts and opening stock value match the signed source reports.
Configure and test the pilot outlet
The team sets up one POS profile for the pilot store, with its warehouse, payment modes, price list and cashier roles, and confirms that Server Scripts or other custom logic are enabled only where the hosting path allows them. Cashiers open and close sessions through test and then live shifts, and the store manager checks the till totals against the sales register at each close. The step is done when several shifts reconcile without manual adjustment and the pilot's sales post correctly to accounting.
Test marketplace and ecommerce order sync
Before the wider rollout, the team connects the Shopify or Amazon accounts to a test environment and runs orders through the full path: order intake, stock reservation, fulfillment, returns and payment settlement. Finance checks that marketplace fees, taxes and payouts land in the expected accounts and that stock levels match across the pilot store, the online warehouse and the channel. The step closes with a written list of mapping exceptions and an agreed owner for each one.
Roll out the remaining outlets in waves
The team adds the other stores in groups, each with its own POS profile, cashier roles and stock transfer routes, and repeats the cashier session checks used for the pilot. Store managers are trained on opening and closing sessions, transfers and returns before their outlet goes live. Each wave is checked for till variances and stock discrepancies before the next group starts. The step is complete when every outlet is live and has a named owner for daily reconciliation.
Run the first month-end review
After the first full month, finance reconciles store sales, card settlements, marketplace payouts and stock movements against the consolidated ledger, and the team reviews every unmatched item. The review also checks whether the hosting path is keeping up, including backups, background jobs and report speed under the live volume. Open issues are logged with an owner and a fix date. The step closes when the month-end figures are signed off and the backlog is either resolved or accepted by the business.
Where custom retail logic belongs and what it risks on hosted sites
Before any loyalty rule, pricing exception or till workflow is designed, the partner and the retailer need to agree where that logic will live, because the answer depends on the hosting model. Server Scripts run Python on document events such as a sales invoice submit, or as API endpoints, and they are a quick way to add retail behavior without touching the codebase. From version 15 onward, though, they are disabled by default and must be switched on with the server_script_enabled setting. The Frappe documentation also states that Frappe Cloud public shared benches do not allow them. A retailer planning to use Server Scripts for a points calculation or a store-specific discount therefore has to confirm, in writing, whether the site is on a public shared bench, a dedicated bench, or infrastructure the retailer controls before the design is fixed.
Loyalty and pricing logic that touches several documents, needs its own tests, or must survive ERPNext upgrades is usually a better fit for a custom app. A custom app is versioned in source control, deployed through the same bench process as the core, and can add DocTypes for points ledgers or tier rules instead of stuffing them into custom fields. It also keeps the logic out of the database where an upgrade or an administrator edit can change it silently. The trade-off is that a custom app is code the retailer owns and must maintain across each ERPNext release, so the partner should estimate that upkeep as a recurring cost in the quote rather than treat the build as a one-time item.
Ask the hosting provider and the partner to confirm five things before design starts: the hosting tier and whether it permits Server Scripts, who can change the server_script_enabled setting, where the bench and its apps are deployed from, how the custom app will be installed on each outlet's environment, and who holds the staging site used for testing. Each answer changes the build. If scripts are blocked, the logic moves into a custom app or an external service, and that change alters both the timeline and the recurring support scope. Confirm these points early, because retrofitting a hosting decision after the loyalty rules are built is one of the more expensive corrections in a retail rollout.
Compliance and control points for retail finance and staff access
Store sales flow into the general ledger, so who can sign in, what each role can change and how imported data is checked all shape the audit trail. The cards below cover the controls to design before the first outlet goes live, and where DeployOpen's evidence work ends and an independent auditor's work begins.
Outlet-level sign-in with LDAP
ERPNext can authenticate staff against Active Directory or OpenLDAP through LDAP Settings, with SSL/TLS options and automatic mapping of LDAP groups to ERPNext roles at each login. For retailers, this lets a store group map to a cashier role and a manager group maps to a supervisor role, so leavers lose access when their directory account is disabled. Confirm how your directory groups map to outlets and who owns that mapping.
Social login for head office users
Social Login Key lets ERPNext users sign in through providers such as Google, Microsoft or custom OAuth or OpenID Connect endpoints. Head office finance and buying staff are often better served this way than shared store logins, but each provider becomes part of your access path. Decide which accounts may sign in this way and confirm how a provider sign-in is linked to an ERPNext user.
Separating cashier and manager roles
A cashier should open and close a POS session and take payments, while a manager approves discounts, voids, returns and cash differences. Define these as separate roles and check that no single user holds both sides of a cash movement. Document the role matrix before go-live and review it whenever a new POS profile or outlet is added.
Audit trail for store sales
Every POS invoice, return and payment entry is a document with a history, so the audit trail is only as useful as the controls around it. Confirm which fields can be edited after submission, how cancellations are recorded, and who reviews the daily cash reconciliation. Test that a voided sale still appears in reporting with its original reference.
Controlled data imports
The Data Import tool loads and updates records from CSV or Excel files, including child table rows, and the documentation advises importing only a few thousand records at a time. Item prices, customer lists and opening stock loaded this way change financial records, so restrict who can run imports, keep the source files and check counts and totals after each batch.
Evidence versus audit opinion
DeployOpen prepares systems, controls and evidence for compliance assessments, such as role matrices, access reviews and configuration records. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make that determination. Tax rules by country, including sales tax and invoice requirements, are not covered here, so confirm them with your tax adviser and local authorities before configuring tax templates.
What retailers ask before hiring an ERPNext partner
What does an ERPNext retail implementation cost?
No single figure applies to every retailer, because the cost follows the written scope. The main drivers are the number of outlets and POS profiles, how many item and price list records need cleaning, whether the online channel needs a sync connector, how many custom scripts or apps are required, and how much data migration is involved. Self-hosting ERPNext itself is free under its open-source license, so the implementation work and infrastructure are the real costs. Ask for a quote that separates one-time work (configuration, migration, testing, training, go-live support) from recurring items (hosting, support plans, upgrades). Each line should name what is delivered.
How long does a retail ERPNext build take?
Duration depends mainly on the number of outlets, the readiness of your data, and the number of integrations. A single-store setup with clean item data moves faster than a multi-outlet chain that needs per-outlet POS profiles, cashier sessions, stock across shops and warehouses, and consolidated store sales in accounting. Online order sync and loyalty rules add their own testing cycles. Ask the partner to state the phases, the sign-off points for each outlet, and the assumptions behind the timeline, such as who supplies data and by when.
What data must a retailer prepare before the build starts?
Prepare four inputs before any configuration begins:
- An item master with codes, names, units, variants, tax templates and barcodes
- Price lists per channel and outlet, with effective dates and any promotional rules
- A list of outlets, warehouses, cashier roles and the accounts each store posts to
- Opening stock counts and customer or loyalty records, with a decision on which history to keep
The ERPNext Data Import tool works from CSV or Excel templates, but its documentation advises importing only a few thousand records at a time, so large item and customer sets need batched loads and checks. Ask the partner which templates they will use and who signs off the cleaned files.
Can our own team build an ERPNext retail system without a partner?
Yes, a capable internal team can build parts of it, especially the basic setup of items, warehouses and a single POS profile. The harder work is usually in the parts that touch money and stock across many locations: consolidating store sales into accounting, reconciling stock between shops and warehouses, and testing order sync with online channels. Server Scripts, for example, run Python on document events, and from version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Assess your team's skills in ERPNext configuration, Python, accounting and integration testing, then decide which parts to keep in-house and which to scope to a partner.
Where can ERPNext be hosted, and what do the listed prices cover?
ERPNext can be installed on Frappe Cloud, with Docker Compose, or manually with the bench command line tool, and it can run on infrastructure you control. The ERPNext pricing page lists self-hosting as free, Frappe Cloud shared site hosting from 5 US dollars per month, and Frappe Cloud servers from 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers. These figures are list prices from that page and may change, so confirm them on the page before budgeting. Hosting fees do not include implementation, and the pricing page notes that implementation is available through certified partners. Note that Frappe Cloud public shared benches do not allow Server Scripts, which may affect your design.
How does the ERPNext version support schedule affect our retail plan?
Frappe publishes a supported versions schedule, and the plan should start on a version that will still be supported for the life of the system. According to Frappe's supported versions page, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. Frappe's policy also says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Ask the partner which version they will build on, the upgrade path to the next major release, and how minor releases will be tested before rollout.
What should a retail ERPNext quote include?
A useful quote lists each outlet and channel in scope, the POS profiles and cashier setup, the stock locations and transfer rules, the loyalty and pricing logic, every integration with its sync direction and frequency, and the data migration batches. It should also name the testing plan, training sessions, go-live support, hypercare period and handover documents. Ask what is excluded, who supplies item and price data, what happens if scope changes mid-build, and what recurring support, hosting and upgrade costs will follow. Most engagements are fixed-scope, so the scope, deliverables and timelines should be agreed in writing before work starts.
Which ERPNext version a retail go-live should target
A retail go-live should target a version that is still inside its support window for the whole planned life of the system, and the first check is the supported versions page maintained by Frappe. According to Frappe's supported versions page, ERPNext and Frappe Framework version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. A store chain that goes live on version 14 today would be running an unsupported stack, so the practical choice is between version 15 and version 16, weighed against how long your POS integrations, Shopify or Amazon connectors and custom scripts will stay compatible with that release line. Confirm the current support page before you fix a version, because dates and listed versions can change, and record the date you checked in the project decision log.
Support is also tied to how you host the system. Frappe's supported versions policy says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. If you run ERPNext on your own servers, ask your implementation partner and Frappe directly what warranty and escalation path applies to your deployment, and whether a Frappe Cloud support plan is required for coverage. Retail teams should also plan for the minor releases that arrive on both supported lines. The frappe/erpnext releases page lists frequent minor versions, so set a patch cadence, test each one against your POS profiles and Shopify sync in a staging site, and budget the time for that testing as a recurring cost rather than a one-time project task.
How DeployOpen scopes and supports an ERPNext retail implementation
DeployOpen plans, implements, customizes, hardens, documents and supports ERPNext inside your own infrastructure, with the store, stock and accounting design agreed before build starts. Most engagements are fixed-scope, with scope, deliverables and timelines confirmed in writing first.
How we scope
- Map each outlet, POS profile, cashier session and warehouse that the written scope covers for your retail operation.
- List which online channels, such as Shopify or Amazon, sync orders, stock and payments, and which stay out of scope.
- Agree in writing how store sales post into accounting, including the clearing accounts, tax treatment and reconciliation owner.
How we build
- Configure POS profiles, item and price structures, and stock locations per outlet before loyalty or channel sync is added.
- Test cashier sessions, returns, stock transfers and end-of-day consolidation with your own sample transactions and sign-off scripts.
- Build any custom scripts or integrations as versioned code, reviewed and deployed through your own change process.
How we hand over
- Document the configuration, integration mappings and known limits so your team can explain each store and channel setup.
- Run a handover session with store managers, finance and IT on daily close, stock adjustments and error handling.
- Provide a list of decisions still owed by your team, such as tax rules or loyalty terms, before go-live.
How we support
- Keep ongoing support, upgrades and testing available as a retainer once the system is live.
- Plan ERPNext version upgrades against the supported version list, with test runs on a copy of your data first.
- Review integration logs, failed syncs and scheduler jobs with your team after each change in outlets or channels.
