Custom distribution ERP development
A distribution ERP is the administrative core of a trading business that makes nothing itself: buying, holding stock, selling, delivering and invoicing. There are no bills of materials or routings, but three questions come up every day: which price applies to this customer, what can I actually promise, and what does this order leave in margin? Appfront builds that core to measure where an off-the-shelf package falls short.
What a distribution ERP does and does not do
A distribution ERP manages the flow of goods for a business that buys and sells without producing anything itself: purchase orders, goods receipts, stock movements, sales orders, dispatch, invoicing and the postings that follow from them. What characterises a production ERP is absent here: no bills of materials, no operation routings, no capacity planning per work centre.
In their place come the questions of which price applies to this customer, what you can genuinely promise given what is in stock and what is already committed, and what margin remains once all back-end rebates have been accounted for. A distribution ERP answers those three questions consistently, whether the order arrives by phone, through the webshop or via EDI.
This page is about that administrative core itself. If you're looking for software around an ERP that stays in place, such as an ordering portal or integrations with your current package, then software for wholesale is the right starting point. Background on our approach and architecture can be found at building a custom ERP system.
From purchase order to general ledger
One continuous thread runs from purchase order and receipt through to sales order, pick instruction, delivery note, invoice and posting. Each step records who changed what and when, so any discrepancy can be traced back to its source.
Price formation as a separate engine
Customer agreements, volume tiers, promotional prices and surcharges come together in a single pricing model that order entry, the webshop and EDI all query. That way the same customer never gets two answers to the same question.
Margin per order line
Revenue minus the actual purchase cost, minus the rebate this customer will still build up later. Only then does it become visible whether an order has earned its keep or merely generated turnover.
At a wholesaler, the price is rarely a single figure
An item has a list price, but hardly anyone pays it. There is a discount matrix by customer and product group, on top of that a contract price for a handful of key accounts, a volume tier that only applies from a certain number of cases, and a promotional price that runs for three weeks. The same item line thus produces three prices for three customers, and two for the same customer depending on the order date.
The interesting question is not whether your system can record all those forms. Almost any package can do that. The question is which agreement wins when two apply at once. Does the promotional price take precedence over the contract price, or not, because that was already negotiated more sharply? Does the volume tier count on the order line, on the order total or on annual volume? At many wholesalers, that answer sits in the heads of two people in the back office. The first real piece of work is making those priority rules explicit and recording, for each order line, which agreement was applied.
On top of that, there are amounts that are not called prices: a surcharge for small orders, packaging and deposits, fuel, or in metals trading an alloy surcharge. They belong to the revenue of the line, yet they often sit in a table that nobody links to the margin.
The hardest are the rebates after the fact. A customer who builds up a turnover rebate per quarter or year buys all year at a price that is correct on the order confirmation and looks perfectly fine in reporting. Only at settlement does it become clear how much must be repaid retroactively across all lines in that period. Anyone who does not build up that rebate as an obligation at the time of the order steers for months on a margin that does not exist. It is better to estimate, per line, the rebate level the customer is heading towards, reserve that amount, and show sales the margin after the expected rebate.
Stock and purchasing: where the administration starts to slip
A wholesaler does not sell items but promises: this quantity, on this date, to this address. That promise is only firm if the system knows the difference between what is on the shelf, what is already allocated and what is in transit. There are four places where this goes wrong.
Physical is not the same as available
Four hundred units are on the shelf, of which three hundred and fifty have been promised to tomorrow's orders. The technical stock says four hundred, the free stock fifty, and the economic stock adds the open purchasing to that and subtracts the sales still to be delivered. Whoever looks at the wrong figure sells goods that already belong to someone else. So do not show a stock figure, show an availability answer.
Stock across multiple locations
As soon as there are two warehouses, an intermediate category arises: goods that are no longer at one location and not yet at the other. Whoever does not record that transfer as stock in transit loses half of an item for a day. On top of that comes the question of which location a customer may be supplied from, and what an urgent transfer costs in freight.
Backorders and partial deliveries
There are twelve units left and three customers want them. Deciding who gets them is a policy choice: first come, first served, by customer priority, or by order value. That choice should be set in the system, not left to whoever happens to have the screen open. After that come the rest: back-ordering or cancelling, invoicing separately or not, and who pays for the extra delivery run. If a customer does not accept partial deliveries, their order should only be released once it is complete. That is a rule in the system, not a note in the customer file.
The invoice price is not the cost price
On import, costs are added on top that only become known later: freight, insurance, customs clearance and import duties according to the commodity code the item falls under. Who bears which cost depends on the agreed Incoterm. The freight invoice arrives weeks after the goods, so the actual cost per unit is not yet fixed on receipt. The system must spread those costs over the consignment afterwards and recalculate stock value and realised margin. Add minimum order quantities and long lead times, and purchasing advice becomes a calculation rather than a gut feeling.
Integrations and standards you can't avoid
A distribution ERP never stands alone. If a WMS runs in the warehouse, the physical truth shifts there and the ERP keeps the administrative one. The most important design decision is then not technical but organisational: which system is leading when the counts differ, and when does the other one correct itself?
For dealings with customers, EDI is in many sectors not optional. The UN/EDIFACT messages you encounter most often are ORDERS for the purchase order, ORDRSP for the confirmation, DESADV for the dispatch advice and INVOIC for the invoice, with PRICAT for price and article catalogues. Underlying this is identification through GS1: a GTIN per article, a GLN per party and location, and an SSCC on the carton label so that the advised shipment and the pallet on the dock are the same unit. Large customers specify their own version of these messages, so expect differing profiles per customer.
Add to that the notification to carriers and track-and-trace feeding back onto the order, and on the invoicing side the European e-invoicing standard EN 16931 with the Dutch implementation NLCIUS, exchanged via Peppol.
If your question goes beyond the administrative core and also involves purchase planning and supplier performance, see supply chain management software.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →When an off-the-shelf package is the better choice
For a wholesaler with a conventional way of working, a mature distribution package is almost always wiser than custom development. Microsoft Dynamics 365 Business Central, Exact, AFAS, SAP Business One and Infor have years of edge cases behind them that you would otherwise have to discover yourself: VAT on intra-EU chain transactions, credit notes landing in the correct period, and stock valuation your accountant will accept. Legislative changes, moreover, arrive with the release.
Do not underestimate what in-house building entails either. You become the owner of every change the legislator demands, of the security, and of knowledge that would otherwise sit with a supplier. An ERP is never finished.
Custom development pays off when it is precisely your commercial model that no package supports: a pricing and bonus structure you will not simplify because you make your margin on it, or units and calculation rules that are normal in your niche but absent from the standard. Often an in-between form works best: the general ledger stays in the package, and we build the trading core around it to measure. If a package is sufficient, we will say so. Present your situation.
Signs that custom development is justified
- Your pricing structure doesn't fit the fields of a package, and simplifying it costs you margin
- Retrospective rebates determine your actual margin and need to be applied at the point of order
- You work with units that the standard doesn't know, such as variable weight or sales by length
- Your largest customers require message profiles that your package does not support
- A feature you need has been on your supplier's roadmap for years
- Your way of working is your competitive edge, not the administration around it
Frequently asked questions about distribution ERP
Often you should. Those packages cover purchasing, stock, sales and invoicing for a typical wholesaler well, and they take care of regulatory changes for you. The balance only shifts when your pricing or rebate structure doesn't fit the standard fields and you don't want to simplify it.
They are rarely documented in full. Some live in spreadsheets, in email and in the heads of the inside sales team. The first phase is therefore an inventory: which types of agreement exist, which precedence rule applies when they overlap, and which agreements have effectively lapsed.
The code and the data are yours. We deliver into your own repository and onto infrastructure you have access to, with documentation of the architecture, the integrations and the rollout. Record the handover in the maintenance contract as well.
Getting locked in is rarely a technical problem and usually stems from undocumented business rules. Make sure pricing, allocation and bonus calculation exist in the system as explicit, testable rules, that integrations run through documented interfaces and that your data remains exportable.
Yes, and that is often the most sensible setup. The custom solution manages items, prices, stock, orders and invoices and delivers postings to the financial package. One agreement is then crucial: which system is leading for debtors, items and open items.
Your administration must remain verifiable and reproducible and falls under the statutory retention obligation for tax records. In practice: gap-free invoice number sequences, no silent changes after the fact but corrections with an audit trail, and a financial audit file your accountant can import. You now monitor that requirement yourself.
Only if all channels call the same pricing engine. If the webshop works from an exported price list, it lags behind as soon as a promotion or a new volume tier takes effect. Build the price calculation as a single service and record for each order line which agreement was applied.
Related services
Software for wholesalers
Ordering portals, warehouse support and integrations around an ERP that stays in place.
Custom ERP system
The broader approach, architecture and phasing behind a custom-built ERP.
Supply chain management software
Purchasing planning, supplier performance and visibility of the chain upstream and downstream of your warehouse.
Want to discuss your pricing structure?
Tell us how your prices, tiers and bonuses are structured and which systems are in place today. We'll be honest about whether a package is enough and where custom software pays for itself, before anything is built. For route visibility across multiple carriers, see the control tower integration.
Another perspective on this topic can be found on applatenmaken.com: building an ERP system.