ERP customer portal vs dealer portal: which one your network needs
An ERP customer portal module covers order entry and account viewing for customers who trade on simple terms. A dealer portal covers the commercial layer above that: per-dealer price resolution, discount tiers, stock visibility rules, credit behaviour, order templates, campaigns and returns. If your dealers all buy from one published list, the module is enough. If pricing is per account, or your network runs to dozens of dealers, a separate portal usually wins once licence and change costs are counted.
Two vendors will answer the same question differently. Your ERP partner will say the customer portal module already covers it and can be switched on in a fortnight. A software house will say you need a dealer portal built around your commercial rules. Both are describing real products, and which one is right depends on facts about your dealer network that neither of them has asked for yet.
This article sets out what an ERP customer portal module actually does, the six areas where it stops, and the conditions that push a distributor network past it. If you are still deciding whether a portal is worth building at all, the case for one is on the dealer portal page. This piece assumes that decision is made and the open question is where the portal lives.
What the ERP customer portal module actually does
Almost every mid-market ERP now ships or sells a customer portal. Their scope converges because they grew from the same idea: give the customer read access to records the ERP already holds, and let them create one document type.
In practice that means:
- Order entry. The customer picks from the catalogue the ERP publishes and creates a sales order, usually as a draft your staff release.
- Account viewing. Open balance, invoice list, statement download, sometimes ageing.
- Order and shipment status. Where a placed order stands, occasionally with the delivery note attached.
- Document access. Invoices, and where the ERP holds them, delivery documents and certificates.
- A price list. Whichever list the customer is assigned to, shown as it is stored.
That is a genuinely useful set of functions, and for a lot of companies it is the entire requirement. It answers the four questions your support line handles all day: is it in stock, where is my order, what is my balance, can you resend that invoice. If those four are your problem, switch the module on and stop reading.
The module’s design centre is worth naming, because it explains everything that follows. It is a window onto ERP records. Whatever the ERP stores, the module can show. Whatever the ERP does not hold as a field, the module has no way to express.
Where the module stops
The gap opens wherever a dealer relationship needs commercial logic the ERP holds only partially. Six areas account for nearly all of it.
Per-dealer price and discount tiers. ERPs store price lists and customer discounts, so the module can show a price. What it often cannot do is resolve a stack: a contract price on one product group, a volume break on a second, a campaign on a third, a payment-term adjustment on the total, in a defined precedence, and then show which rule produced the figure. Where your ERP’s pricing engine genuinely handles the whole stack, the module inherits that and you are in good shape. Where part of the stack is resolved by your sales team from memory or a spreadsheet, the module will publish a price that is confidently wrong.
Stock visibility rules. The ERP holds a quantity. Dealer relationships rarely want the customer to see it raw. What most companies want is a rule: show a band rather than a number, exclude stock allocated to another channel, hide warehouses the dealer cannot be served from, show a lead time instead of zero when the item is inbound. Modules that expose stock generally expose the number they hold, and the rule you want has nowhere to live.
Credit limit behaviour. The module can display a limit and a balance. The real question is what happens at checkout when the limit is exceeded, and there are at least four defensible answers: accept and flag, hold for finance approval, redirect to card payment, or block on open account until the overdue documents clear. Most modules implement one, chosen by the vendor. If your policy is one of the other three, that is a boundary rather than a configuration screen.
Order templates and reordering. A dealer ordering the same sixty lines every fortnight will not click through a catalogue. Repeat from history, saved templates, SKU paste, spreadsheet upload and grid entry for size and colour are what make a portal get used rather than merely deployed. Standard modules typically offer a repeat-last-order button and stop there.
Campaigns. A dealer campaign is not a coupon code. It is conditional: this quantity of group A unlocks a rate on group B, inside a window, for a dealer tier, capped per account. Few ERPs hold that shape as data, which means the missing piece is usually upstream of the portal module rather than in it.
Returns and warranty. This is the requirement that most often settles the question, because it is a workflow rather than a record. The dealer wants to open a return with photographs and a serial number, get a decision, receive an RMA reference, follow the replacement, and see the credit note when it is issued. That crosses sales, logistics, quality and finance. The ERP holds the end result, the credit note. The steps that produce it often live nowhere at all, so there is nothing for a window to look at.
Permission depth in a multi-dealer network
ERP portal modules generally model one customer account with one login, or several logins with identical rights, because the ERP’s user model was designed for employees rather than trading partners. A real dealer network needs more depth than that.
- The dealer as a commercial identity. One dealer may have several delivery addresses and occasionally two legal entities. The first is a single identity, the second is two.
- Sub-users inside a dealer. A branch buyer who raises orders, a manager who releases them, an accounts contact who sees the balance but not the prices, a warehouse user who sees only shipments.
- Regional structure on your side. A representative who sees their own dealers, a regional manager who sees the region, a director who sees everything, all on the same screens.
- Attribution to the person, not the account. When a representative places an order in a dealer’s name, the record has to say so. Without that, the audit trail becomes an argument.
None of this is exotic. It is what a network of more than a few dozen dealers looks like on a normal Tuesday. But it is a permission model, and permission models are the hardest thing to add to a product afterwards. This is the axis on which the plan to start with the module and extend later most often fails: the extension is not a feature, it is a rewrite of who is allowed to see what.
Integration direction: in front of the ERP, or inside it
There are two architectures, and the difference is about record ownership rather than technology.
The module as a window. One database, nothing duplicated, nothing that can disagree, no reconciliation to write. The cost is that the portal can only be as expressive as the ERP schema, and every portal change is an ERP change, with the change control and vendor dependency that implies.
A portal in front of the ERP. A separate application with a bridge. It holds its own data for the things the ERP does not model, and the ERP stays the system of record for everything financial.
The second only works if ownership is decided before anything is built. A division that holds up in practice:
| Record | Owner | Direction and refresh |
|---|---|---|
| Product master, units, variants | ERP | ERP to portal, scheduled |
| Base price lists and customer assignments | ERP | ERP to portal, scheduled |
| Dealer-specific rules, tiers, campaigns | Portal | Authored in the portal, carried on the order |
| Stock | ERP | ERP to portal, near real time, visibility rule applied in the portal |
| Credit limit, balance, ageing | ERP | ERP to portal, near real time, read only |
| Order | Portal until confirmed, ERP after | Written to the ERP as a sales order with resolved prices |
| Invoice, credit note, ledger | ERP | Portal displays only |
| Return case | Portal owns the workflow | ERP owns the resulting credit note |
| Dealer users and permissions | Portal | Usually not represented in the ERP at all |
Whichever direction you choose, a nightly reconciliation that compares open orders, balances and stock across both sides and reports differences to a named person is not optional. A bridge without one looks correct right up to the day it is not. How that bridge is built for each family of back end is described on integrations.
Decision table
| Situation | ERP portal module | Separate dealer portal | Recommended |
|---|---|---|---|
| All dealers buy from one published list | Sufficient | Unnecessary cost | ERP module |
| Price resolves from a stack of contract, group, volume, campaign | Shows one stored price | Rule engine, with the rule shown on the line | Separate portal |
| Some contract prices live outside the ERP | Publishes the wrong price with confidence | Rules move into one engine | Fix the data, then decide |
| Dealers reorder the same lines weekly | Repeat-last-order at best | Templates, paste, upload, grids | Separate portal |
| Credit rule is not the vendor's default behaviour | Fixed by the module | Policy is a configuration | Separate portal |
| Sub-users inside a dealer need different rights | Usually one login per account | Role tree per dealer | Separate portal |
| Returns and warranty visible to the dealer | Not modelled | Case workflow with an RMA reference | Separate portal |
| External users are licensed per seat | Recurring cost scales with the network | One-off build plus maintenance | Run the arithmetic before deciding |
| ERP replacement plausible within two years | Portal leaves with the ERP | Bridge is rewritten, portal survives | Separate portal |
| Few dealers, occasional negotiated orders | Adequate | Hard to justify | Module, or neither |
| No internal owner for master data | Publishes errors to dealers | Publishes errors to dealers | Neither yet |
One sentence summarises the table: if the ERP already stores the answer, a module can show it; if the answer has to be worked out, it needs somewhere to be worked out.
The licence cost trap
The line item that most often changes a decision late is per-user licensing, and it is the one nobody checks in week one.
ERP licences are usually priced per named user or per concurrent session. Portal access is variously included in the base licence, sold as a separate module with its own user band, or charged per external user. Three questions, answered in writing, before any comparison is honest:
- Is a dealer logging into the portal a licensed user, and at what rate?
- Is the count named or concurrent, and does a sub-user inside a dealer count separately?
- What is the next band, how large is it, and what does it cost to cross?
Then run the arithmetic on your projected numbers rather than today’s. Forty dealers averaging two and a half users each is a hundred accounts, not forty. And note the direction of travel: a portal is usually justified by an intention to grow the network, while per-user pricing charges you more for exactly the outcome you are buying it for.
The comparison is not that the module is cheap and custom is expensive. It is a recurring cost that scales with dealer count set against a one-off build cost that does not, plus maintenance on both. Where those two lines cross depends entirely on your per-user rate and your network size, which is why a vendor offering a general answer has not asked enough questions. Our own build and maintenance bands are on the dealer portal page; the point here is the shape of the two curves rather than either figure.
What happens when the ERP changes
Mid-market ERPs get replaced. Not often, but on a horizon shorter than the life of a dealer network, and usually for reasons that have nothing to do with the portal: an acquisition, an end-of-support date, a move to cloud, a finance team that has had enough.
If the portal is a module inside the ERP, it leaves with the ERP. Your dealers lose their login, their order history, their saved templates and the habit you spent a year building. That last one is the expensive part. Adoption is the hardest thing about any dealer portal, and it rarely survives asking the same people to learn a second one two years later.
If the portal is a separate application, an ERP change is a bridge rewrite: real work, roughly on the scale of the original integration effort rather than the original build, and confined to one layer. The dealer-facing surface does not move, the URL does not change, the history and the price rules stay.
This is not by itself a reason to build separately. It is a reason to ask one question before choosing. How confident are you in this ERP for the next five years? A confident answer makes the module more attractive than the table above suggests. An uncertain one makes coupling your dealer relationships to that decision an expensive way to save money now.
The data you need before you start
Whichever direction you pick, the same facts decide the scope, and you already have all of them.
- Dealer count and user count. Not the same number. Ask three representative dealers how many of their people would need a login.
- Order frequency and lines per order. Weekly orders of fifty lines and monthly orders of three lines are different products.
- Your price resolution order, written down. Which rule beats which, agreed by the commercial team rather than assembled by whoever happens to be asked. If two people give different answers, that is the first finding of the project, and the exercise is worth doing regardless of what you end up building.
- How many prices live outside the ERP. Count the contract prices held in a spreadsheet, an email thread or someone’s memory. That number predicts whether the module will be enough better than any other single figure.
- Master data condition. Product codes, units, variants, price list assignments. A portal publishes your master data to your customers at full confidence, so errors that were survivable internally become visible externally.
- Your credit policy at checkout, expressed as a rule. Which of the four behaviours do you actually want, and who approves the exception.
- Your ERP’s portal licensing, in writing, at your projected dealer count. Not at today’s.
- Whether order intake will move onto the portal by policy. If both channels stay open indefinitely, neither option pays back, because you will have added a system without removing any work.
The last item is not a technical question and it decides more outcomes than the rest combined. Rollout across a distributor network, including how to get dealers to actually switch channel, is worked through in B2B ordering portal for international distributors.
Next step
If you want a straight answer rather than a longer article, send us those eight items, or as many of them as you have to hand. What we do with them is unglamorous: check how much of your price stack resolves inside your ERP, price the licence line at your projected dealer count, and tell you which option your own numbers point to, including the cases where that is the module you already own. The scope of what we build when it is not is on the dealer portal page, and the eight items go through the quote form.
Once the choice is made, the build hinges on the ERP seam: see writing orders into SAP Business One and Business Central.
Frequently asked questions
Does our ERP already include a dealer portal?
Most mid-market ERPs sell a customer or B2B portal module, and their scope is more similar than the datasheets suggest: order entry, balance and invoice viewing, order and shipment status, and the price list the customer is assigned to. That is a real product and for many companies it is the whole requirement. What it is not is a dealer portal, because it can only express what the ERP already stores as a field. Ask your vendor which of your pricing rules the module resolves, and the answer will draw the boundary for you.
Which system owns the order once a portal sits in front of the ERP?
The portal creates it, the ERP owns it from acceptance onward. The portal is where the order is composed, priced and approved, because those steps use rules the ERP may not hold. The moment it is confirmed it is written to the ERP as a sales order carrying the resolved prices and the rules that produced them, and from then on the ERP is the system of record for fulfilment, invoicing and the ledger. A nightly reconciliation compares open orders, balances and stock on both sides and reports differences to a named person.
Do we need an ERP user licence for every dealer?
Sometimes, and it is the line item that most often changes a decision late. Portal access is variously included in the base licence, sold as a separate module with its own user band, or charged per external user. Get three answers from your vendor in writing before comparing anything: is a dealer login a licensed user and at what rate, is the count named or concurrent, and does a sub-user inside a dealer count separately. Then run it at your projected dealer count rather than today's, because a portal is usually bought to grow the network.
What happens to the portal if we replace our ERP?
A module inside the ERP leaves with the ERP. Your dealers lose their login, their order history, their saved templates and the habit you spent a year building, and that habit is the expensive part. A separate portal survives an ERP change as a bridge rewrite: real work, roughly on the scale of the original integration effort rather than the original build, but confined to one layer. The dealer-facing surface, the URL, the history and the price rules all stay. How confident you are in your ERP for the next five years is therefore part of this decision.
How many dealers justify a separate portal?
Dealer count alone does not decide it, and any figure quoted without your other numbers is a guess. Three things move the line: how much of your price stack resolves inside the ERP rather than in a spreadsheet, how often dealers reorder, and what external users cost on your licence. Ten dealers on fully contracted per-account pricing can justify a portal, while eighty dealers all buying from one published list may not. Count the prices that live outside your ERP first; that number predicts the answer better than headcount does.
Related guides
- AI automation: how European, Gulf and Turkish buyers differ
- AI workflow automation vs RPA: choosing the right layer
- Custom ERP vs SAP: what actually decides it for a mid-size manufacturer
Service page: Package vs custom
Let's talk about what you need.
The 30-minute discovery call is free and carries no commitment.