ERPNext for distributors and wholesalers

Why ERPNext fits a distributor's stock, pricing and credit problem

ERPNext covers distribution, but it covers it through configuration and, in some cases, custom work, and the boundary depends on the version and the apps you choose. A distributor with many SKUs, several warehouses, customer-specific prices and imports carrying landed cost needs order management, inventory and accounting to work from the same records. ERPNext is built to do that: it is a free and open-source ERP system covering accounting, order and inventory management, manufacturing, asset management and projects, built on the Frappe Framework. Its core code is licensed under GPL-3.0, while the Frappe Framework is licensed under MIT, so review both licenses with your legal team before you plan any distribution of modified code.

The practical question is not whether the modules exist but which of your rules they already express. Warehouse structure, putaway logic, pick lists, price lists by customer, blanket orders, landed cost allocation and credit limits each need to be designed against your own processes. Confirm with the implementation partner which of these are standard settings in your target version, which need custom fields or scripts, and which need a separate app or integration. Server Scripts, for example, are disabled by default from version 15 and must be enabled, and public shared hosting does not allow them, so that choice affects where you can build. Ask for a written fit assessment that maps each distribution rule to one of those three outcomes before you commit to a scope.

Distribution requirements and what each means for the build

This table maps the core distribution requirements to what each one asks of ERPNext configuration, data or custom work. Read each row as a question to settle in scoping, with the source for any platform behavior we could confirm. Rows marked as items to confirm need a check against the target version before the build is priced.

Requirement	What it asks for	What it means for the build
Multi-warehouse stock	Separate stock locations for each depot, branch or consignment site, with transfers between them	Configuration of warehouse hierarchy, default warehouses per customer or region, and a data load that sets opening balances per warehouse. Confirm reporting needs per location during scoping.
Putaway and pick lists	Rules that direct received goods to bin locations and build pick lists for orders	Confirm how far standard pick list and putaway behavior covers your bin layout. Anything beyond it, such as wave picking or zone logic, is likely custom work and should be scoped separately.
Price lists by customer	Different prices for customer groups, contracts or territories, with discounts applied at order entry	Configure price lists and pricing rules, then load customer price data through the Data Import tool in batches. The Data Import documentation advises importing only a few thousand records at a time, so plan the price file in stages.
Blanket orders	Agreed quantities and prices released against call-offs over a period	Confirm the blanket order flow and release tracking against your contract types during scoping. Tracking partial releases across warehouses may need custom reports or scripts.
Landed cost on imports	Allocating freight, duty and handling to purchase receipts so item valuation reflects true cost	Configure landed cost vouchers and the allocation basis your finance team uses. Confirm the allocation method and how it posts to stock valuation with your accountant before go-live.
Credit limits	Blocking or warning on orders when a customer exceeds an agreed exposure	Confirm whether standard credit limit settings match your rules, such as credit days or overdue exclusions. Custom logic is often written as a Server Script, and per the Frappe Framework documentation, Server Scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting. Shared hosting environments may not allow them.
Marketplace and ecommerce order intake	Orders from storefronts or marketplaces flowing into sales orders with stock and payment status	Confirm which connector covers your channels, what it syncs and in which direction, and how stock levels are updated. Connector scope is covered on the ERPNext integrations pages, so verify it for each marketplace before committing to a timeline.
Validation and approval rules	Checks on pricing, discounts, margins or order values before submission	Usually built as custom validation or workflow logic. Confirm the rule set and approvers in scoping. Server-side logic that runs on document events depends on the Server Script settings noted above.

Which ERPNext modules and settings matter for distributors

A distribution back office depends on a small set of ERPNext configuration choices that are hard to change once transactions exist. The cards below cover the stock, pricing, order cycle, costing, credit and data loading decisions that shape the rest of the implementation.

Warehouse and stock structure

Warehouses, stock locations and the rules for moving goods between them define where inventory lives and how it is counted. Decide how many warehouses to model, whether bins or sub-locations are needed for putaway, and which warehouse each sales and purchase transaction draws from by default. Also decide whether serial or batch tracking applies to any item group, since that setting is difficult to reverse once stock moves. Confirm how transfers between warehouses in transit will be recorded before go-live.

Pricing rules and price lists

Price lists separate selling rates by customer group, territory or channel, while pricing rules apply discounts or margins on top of them. Map each customer tier to a price list, then decide which discounts are set by rule and which are entered manually on the order. Agree who may override a price and whether overrides need an approval step outside ERPNext. Test a sample of negotiated customer prices against the configured rules before loading the full customer list.

Blanket orders and the order cycle

Sales and purchase orders move through quotation, order, delivery note or purchase receipt, and invoice. Blanket orders let a customer or supplier commit to a quantity or value over a period, with releases drawn against it as deliveries happen. Decide which contracts need blanket treatment, the validity period each one carries, and whether releases are invoiced per delivery or per period. Confirm how partial deliveries and returns reduce the open balance of the agreement.

Landed cost vouchers on imports

A landed cost voucher spreads freight, duty, insurance and clearing charges across the purchase receipt items they relate to, so that stock valuation reflects the true cost of goods. Decide which charge types your import flows generate, which allocation basis fits each one (by amount, quantity or weight), and whether charges arrive on separate supplier invoices. Check how a voucher posted after goods have been sold affects cost of goods sold, and agree the posting period with your accountants.

Credit limits and credit control

Credit limits set the maximum outstanding balance a customer may carry, and ERPNext can block or warn when an order would exceed it. Decide the limit per customer or customer group, who may raise a limit, and whether overdue invoices should stop new orders or only trigger a warning. Define the exceptions path for trusted accounts, and confirm which roles can change credit settings. Review the limits with finance on a fixed schedule, since they drive collections as much as sales.

Data Import for item and customer masters

Item, customer, supplier and price masters are the foundation for every transaction, so their load order and quality matter more than their volume. The Data Import tool loads and updates records from CSV or Excel files using downloadable templates, and the documentation advises importing only a few thousand records at a time. Prepare batches in dependency order (item groups, UOMs, items, customers, then prices), run a trial import on a copy of the site, and keep the source files that produced each batch for audit.

Choosing where a distribution ERPNext runs

Frappe Cloud is the hosted option run by Frappe, where ERPNext is installed and maintained on infrastructure you do not operate yourself. It suits a distributor that wants a supported starting point without building a server team, but it moves hosting decisions onto the vendor's platform and its plan rules.

Hosting tiers: Frappe Cloud shared site hosting starts at 5 US dollars per month, and servers start at 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers, according to the ERPNext pricing page.
Data residency: Your data sits on the hosting platform, so confirm the hosting region, backup locations and any sub-processors before you sign.
Server Scripts: Frappe Cloud public shared benches do not allow Server Scripts, so warehouse or credit-limit logic that depends on them needs a dedicated bench or a custom app.
Maintenance: Frappe operates the platform, but your team still owns configuration, master data quality and testing of each upgrade.
Warranty: Frappe's supported versions policy ties warranty coverage to running a listed version with a matching Frappe Cloud support plan.

Check the plan tier against your order volume, custom code and backup retention needs before you commit.

Moving item, customer and open-order data into ERPNext

A distributor's first data load is usually item masters, customer records with their price lists, opening stock and open sales orders, and the order in which these are loaded matters because each record links to the ones before it. Items and customers must exist before stock, prices or orders can reference them. The Data Import tool in ERPNext loads records from CSV or Excel files, or from public Google Sheets, using downloadable templates, and it supports child table rows so that item rows can sit inside a Sales Order or a price list can be loaded with its items. Agree the load sequence in writing before anyone prepares a file, and keep each step in its own template so a failed batch can be rerun without touching records already loaded.

The ERPNext documentation advises importing only a few thousand records at a time, so plan the volume as batches with a named owner, a start and stop point, and a log of what was created or updated. Test the full sequence on a copy of the target site first, then count records per DocType in the source system and in ERPNext after each batch. Opening stock and open orders need the most attention: confirm quantities by warehouse and unit of measure, check that open sales orders do not reference items or customers that failed to load, and agree which pricing rules and customer price lists are carried over and which are rebuilt. Do not assume an export from the old system reflects reality until the business has checked it.

The client owns the reconciliation and sign-off. Finance should approve opening balances, the stock controller should approve counted quantities per warehouse, and sales operations should approve open order lines and customer credit terms before go-live. Ask the implementation partner to deliver reconciliation reports per batch, an exceptions list with reasons, and a signed record of each approval. Confirm with your own team whether credit limits, blanket order quantities and landed cost inputs are migrated or entered fresh, since each one changes what must be checked.

What do distributors ask before hiring an ERPNext partner?

What drives the cost of an ERPNext distribution implementation?

The main cost driver is the number of decisions the build must cover, not the software itself, which is free under the GPL-3.0 license. Cost rises with the number of warehouses and stock locations, the complexity of customer price lists and pricing rules, the number of source systems to migrate, custom apps or server scripts, and integrations with marketplaces, payment gateways or shipping tools. Hosting is a separate line: the ERPNext pricing page lists Frappe Cloud shared site hosting from 5 US dollars per month and dedicated servers from 125 US dollars per month, and self-hosting carries no license fee. Ask for a fixed-scope quote that lists each warehouse, price list, integration, migration source, custom build and training session as a separate deliverable, and states which items recur (hosting, support, upgrades) and which are one-time.

How long does a distribution rollout take and what makes it longer?

Duration depends on how many processes must be designed before any configuration starts, and on how clean the client's item and customer data already is. Rollouts usually run longer when stock must be tracked by serial or batch, when landed cost on imports must match accounting, when pick and putaway rules differ by site, or when several legacy systems feed the new one. The Data Import tool documentation advises loading only a few thousand records at a time, so large item or customer masters add load and validation cycles. Ask the partner for a timeline split into design, build, data migration, testing and go-live, with the client sign-offs that gate each phase.

What must our team supply before the build starts?

Your team must supply the decisions and data that the system cannot infer. The usual inputs are:

Item master data, including units of measure, item groups, reorder levels and any serial or batch requirements
Customer and supplier records, with credit limits, payment terms and the price list each account uses
Pricing rules, discount approval levels and blanket order terms
A warehouse layout with bins, putaway logic, pick routes and transfer rules between sites
Landed cost components for imports, such as freight, duties and insurance, and how each is allocated
Named business owners who sign off each design document and the go-live cutover

Missing or slow sign-off is one of the most common causes of schedule slip, so agree on the sign-off roles at the start.

Can an internal IT team implement ERPNext for distribution without a partner?

Yes, an internal team can implement ERPNext, because the software is open source and the documentation and community are public. The harder question is whether the team has time and experience with stock valuation, accounting integration, data migration and the Frappe build model. A partner is most useful for the design work on pricing and warehouse logic, for migration and reconciliation, and for custom apps or integrations that must be maintained. Ask yourself whether you will have people who can own the system after go-live, including upgrades and security patches, because that work continues for the life of the system. Any partner should show you a written scope that lets you compare the work against your own plan.

How do hosting options change day-to-day operations?

Hosting decides who patches the platform, who handles backups and who answers when the scheduler or background jobs stall. Frappe Cloud is a managed option with published starting prices, and the Frappe support policy states that warranty coverage requires a listed version and a matching Frappe Cloud support plan. Self-hosting on your own servers or private cloud, using bench, Docker Compose or Kubernetes, gives you control over data location and network access, but makes your team responsible for database tuning, TLS, backups, the scheduler and storage growth. Note that Frappe Cloud public shared benches do not allow server scripts, which affects custom automation. Confirm these constraints before choosing a hosting model.

How are upgrades between supported ERPNext versions handled?

Upgrades move between major versions, and the supported versions page sets the planning dates. ERPNext and Frappe 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. Both supported majors receive frequent minor releases, so plan a regular patch cadence in addition to major upgrades. A major upgrade should be tested on a copy of production data, with custom scripts, print formats and integrations re-checked against the new version. Ask the partner how they test custom apps, what rollback looks like, and whether upgrade work is included in a retainer or quoted separately.

What should a fixed-scope quote for distribution include?

A fixed-scope quote should list the agreed deliverables, the exclusions, the client responsibilities and the acceptance criteria. For distribution, expect separate line items for company and chart of accounts setup, warehouse and stock configuration, pricing and price list design, blanket orders, landed cost, credit limit rules, ecommerce or marketplace order intake, data migration with reconciliation reports, user training, testing and go-live support. Ask whether the quote covers the hosting setup, the post-go-live warranty period, and any change requests and how they are priced. Also ask what is one-time and what recurs, such as hosting, support plans and upgrade retainers.

How a distribution rollout moves from scope to go-live

The sequence turns a written scope into a running ERPNext system where warehouses, prices, credit terms and order intake have been tested against real transactions before staff depend on them. Each phase closes with a sign-off that the next phase relies on.

Agree scope and design the warehouse model
Before any configuration, the team agrees in writing which warehouses, branches and selling entities ERPNext will hold, how stock moves between them, and which item groups carry serial or batch tracking. DeployOpen maps your current stock locations, pick routes and putaway practices against ERPNext warehouse structure and records the decisions in a design document. The step is done when your operations lead and finance lead have signed the warehouse tree, the stock flow diagram and the open questions list.
Configure pricing, credit and stock rules
The team builds the item master, price lists by customer group, pricing rules, blanket order terms, credit limits and the stock settings that govern reservations, putaway and pick lists. Each rule is traced back to a sentence in the design document so that reviewers can check intent against configuration. The step closes when a set of test sales orders, one per pricing scenario, produces the prices, credit decisions and pick lists that the business signed off.
Migrate and reconcile opening data
Item, customer, supplier and opening stock records are loaded in controlled batches, starting with a small sample, using the Data Import tool and templates. Each batch is reconciled against the source system for counts, stock value and open receivables and payables, and differences are logged with an owner. The step is complete when stock quantities and valuation, open balances and open orders match the agreed reconciliation pack, with any accepted differences documented.
Test integrations and order intake
Ecommerce, marketplace and payment connections are tested end to end with sample orders covering normal sales, returns, cancellations, partial shipments and failed payments. The team checks that each order creates the expected sales order, reservation, delivery and invoice, and that stock and status changes flow back to the channel. Testing is complete when every scenario on the agreed test list has a recorded result and the exceptions queue is understood by the operations team.
Load landed costs and test import flows
For importers, the team tests purchase receipts with freight, duty and insurance allocations and confirms how landed cost changes item valuation and margin reports. Inbound flows, including supplier returns and stock reposting, are exercised with real document examples from the business. The step closes when valuation after a test import matches the figures that finance calculated by hand for the same shipment.
Run in parallel and fix exceptions
For a period agreed in the plan, the business keeps the existing process running while the new system processes the same live activity, and the two outcomes are compared daily. Discrepancies in stock counts, prices, credit holds or invoices are classified, fixed in configuration or training, and retested. The parallel run ends when the agreed exception threshold is met and the steering group signs the cutover decision.
Go live and provide hypercare
The cutover runs from a frozen data snapshot, with final stock counts, open orders and the reconciliation pack confirmed on the day. After go-live, DeployOpen provides hypercare for the period set in the written scope, covering stock discrepancies, order intake issues, user questions and performance on busy days. The phase closes when the hypercare exit checklist is signed and open items have named owners in your support process.

Compliance and control points in distribution ERPNext

Distribution ERPNext touches receivables, pricing, stock valuation and integration credentials, so the controls sit across several layers at once. The cards below cover the decisions to make in the build, the evidence each one leaves behind, and where your advisers need to confirm the obligations that apply to your business.

Credit control and approvals

ERPNext lets you set a credit limit per customer and decide what happens when a sales order would exceed it, such as a warning or a block. Decide which roles can raise a limit, who approves an overdue account going back on credit, and whether sales orders above a threshold need a second sign-off. Check that the limit logic is enforced on the server, not only in the form, and test it with a user who has sales rights but no approval rights.

Role and permission design for pricing

Pricing rules and discounts are where margin leaks, so restrict who can create or edit price lists, pricing rules and item-level discount fields. Separate the roles that set prices from those that apply them on orders, and consider limiting discount percentages by role. Review user permissions so that a regional sales user sees only the customers and price lists for their territory.

Audit trails for stock and invoice changes

Stock movements, invoice edits and cancellations must be traceable to a user and a time. Confirm which document changes ERPNext records in its version history, how cancelled and amended documents appear in reports, and whether stock reposting entries are restricted to a named group. Agree with your auditors which reports and logs they will sample, and export them on a schedule so evidence is not left only in the application.

Secrets and integration credentials

Marketplace connectors, payment gateways, bank feeds and shipping APIs each hold credentials that can move money or stock. Store API keys and tokens in the appropriate encrypted fields, restrict who can view them, and rotate them on a documented schedule. Keep credentials out of exported customizations and of server scripts, and confirm that backups containing them are encrypted and access-controlled.

Access controls for LDAP or social login

If staff sign in through Active Directory or OpenLDAP, ERPNext can map directory groups to ERPNext roles at each login, so removing a person from a group removes their access. Social login through an identity provider works similarly, with its own policies for federation and sign-in. Define who is authoritative for joiners, movers and leavers, test a deprovisioned account, and confirm that local administrator accounts remain under separate control.

Server scripts and change control

Server Scripts run Python on document events, so they can change financial or stock behavior. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Decide whether your environment permits them at all, and if so, route every script through version control and review before it reaches production.

Keeping a distribution ERPNext on a supported version

Keep your distribution ERPNext on a version that Frappe still supports, because support status decides whether you get warranty coverage at all. 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 requires customers to run a listed version and hold a matching Frappe Cloud support plan to receive warranty coverage from Frappe. If you self-host, confirm with your implementation partner and Frappe which support arrangement applies to your deployment, and write the answer into your support contract before you plan any upgrade work.

Both supported major versions receive frequent minor releases. The frappe/erpnext releases page showed v16.51.1 and v15.123.0 released within a day of each other in October 2026, so a patch cadence is normal and should be scheduled, not feared. Agree a fixed patch window with finance and warehouse leads, and avoid the last working days of the month, the days when period closing entries are posted, and the days a physical stock count is being reconciled. A minor update that changes stock posting logic in the middle of a count can make the count difference hard to explain, so freeze stock transactions or agree a cut-off before applying it.

Plan major upgrades as separate projects with their own test cycle, not as patches. Take a copy of production, run the upgrade there, and reconcile a sample of stock ledger entries, valuation totals, open sales orders, blanket order balances and customer credit limits against the pre-upgrade figures. Ask your partner to document the breaking changes for each step and the custom scripts or custom apps that must be retested. Choose a quiet period outside month-end and outside your main stock count, and keep a tested rollback point for the database and the bench before you start.

How DeployOpen works on this

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports ERPNext inside your own infrastructure, including the distribution workflows described above. Work starts from a written scope that names the warehouses, price lists, credit rules and order channels in play, so the build matches how your business sells and ships.

How we scope

Map warehouses, transfer routes, putaway rules and pick list practice before any configuration begins.
Document pricing rules, price lists by customer group and blanket order terms in the written scope.
Confirm landed cost sources, credit limit ownership and which marketplace or ecommerce channels feed orders.

How we build

Configure stock, pricing and credit settings, then test them with sample orders from each sales channel.
Write customizations as custom apps or exported configuration rather than edits to core ERPNext code.
Plan data migration with the Data Import tool in batches, reconciling item, customer and opening stock counts.

How we hand over

Deliver the configuration record, role matrix, integration map and test scripts used during acceptance.
Walk your operations and finance staff through pick, pack, invoice and return flows on your own data.
Document the upgrade path for the ERPNext and Frappe versions in use, including any server script settings.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live, scoped in writing.
Review new ERPNext minor releases against your custom apps and integrations before they reach production.
Confirm with us which support terms, hosting plan and version lifecycle apply to your environment.