Four measurements to take this week
Each of these takes under an hour and together they decide the project. Take all four before you form a view, because the fourth one frequently reverses the conclusion the first three suggest.
The point of measuring rather than arguing is that everyone in the building already has an opinion about the spreadsheet, and the opinions are usually about how annoying it is rather than about what it costs.
Version count. Email five dealers, chosen across your size range, and ask them to send back the price file they are working from today. Count the distinct dates. Three or more distinct versions in a sample of five means the field is not on one price book, whatever your records say.
Change latency. Take your most recent price change. Write down the date it was approved internally and the date you can prove the last dealer had it. The gap is your true price-change lead time and it is usually weeks longer than anyone claims.
Stale-price order rate. Count last month’s dealer orders that had to be repriced at order entry. Express it as a percentage of dealer orders. This is the number that converts an irritation into a figure.
Where the prices live. Open the spreadsheet and ask whether every price in it could be produced from your ERP today. If the answer is no, the spreadsheet is not a portal problem, it is your pricing system, and that changes the whole project.
What do the four measurements mean together?
Read your four numbers against this table. The rows are not mutually exclusive and most manufacturers land on two of them. Where the last row applies, it outranks everything above it, because you cannot publish prices you cannot produce.
| Criterion | What you measured | What it means | What to do |
|---|---|---|---|
| Several live versions, low stale-price order rate | The field is on different sheets and it is not yet costing you money at order entry. | Your dealers are checking with you before they order, which is why the errors are not showing up. You are paying for it in phone calls instead. | Publish one authoritative price list behind a login before you build anything transactional. A gated, dated price page removes the version problem on its own. |
| Long change latency, prices change several times a yearThis is the measurement that most often wins a budget, and it is the one nobody takes. | Weeks between an approved price change and the last dealer working from it. | Every price rise is partially uncollected for as long as the latency lasts, and every price cut reaches your competitors’ customers before yours. | This is the clearest financial case for a portal. Put a number on the latency using your own volumes and take it to your CFO. |
| High stale-price order rate | A meaningful share of dealer orders get repriced at entry, and someone has that conversation with the dealer. | You have already paid for a portal in order desk time and dealer goodwill. The work is happening, just not in software. | Move ordering online for the dealers who generate most of the reprices, not for all of them. Adoption is easier when it starts with the people already in pain. |
| The prices cannot be produced from the ERP | The spreadsheet contains rates, break quantities or dealer-specific columns that exist nowhere else. | The spreadsheet is your pricing system. A portal built on top of it would need the same spreadsheet as its source, which is a spreadsheet with a website attached. | Move pricing into the ERP first, as a project with its own budget. That is the phase one nobody wants to hear about and it is the one that makes everything after it possible. |
What is the honest path from a spreadsheet, in order?
Four steps, and each one is worth doing on its own. The mistake is to attempt step four first, because that is the step that gets presented in demos.
Steps one and two need no commerce platform at all, and between them they remove the two complaints dealers actually make: I did not know the price changed, and I could not find the current file.
One authoritative price file, dated, in one place, produced from the ERP. Stop emailing attachments and start emailing a link, so there is exactly one live version.
Gate it behind a login per dealer so each dealer sees their own prices rather than a general sheet with a discount code attached.
Accept orders as a structured upload against that price list, so the dealer’s order arrives already priced and your order desk stops re-keying it.
Replace the file with a catalogue: search, availability, reorder from history, and the price list underneath it. This is the storefront, and it is the last step rather than the first.
Checked against: Acumatica community 11823: price lists move only when the Price List entity is prepared and processed, Cin7 Core help: pricing and price tiers, read 20 August 2026
When is the spreadsheet still the right answer this year?
There is a real case for leaving it alone, and any page that would not say so should not be trusted on the other cases. Four conditions, and if you meet three of them the spreadsheet stays until something changes.
The condition that matters most is the last one. If your prices do not exist in your ERP in a form a system could publish, then a portal project is really a pricing project with a website at the end of it, and running them as one project is how the budget doubles and the date slips. Do the pricing work, prove it by producing the price book from the ERP for two cycles, and then talk about a portal.
A useful interim that costs almost nothing: publish the current price file as a dated, login-gated page rather than an attachment. It solves the version problem, which is the complaint your dealers actually voice, without committing you to a platform.
You have a small dealer network, small enough that you know every buyer by name and could phone all of them in an afternoon.
Prices change once or twice a year on a predictable cycle, so change latency is not costing you margin.
Dealer orders already arrive structured, by EDI or as a consistent file, so the order desk is not re-keying them.
Your prices do not exist in the ERP in a publishable form, which means the first project is pricing, not commerce.
Checked against: Acumatica community 17608: only Default Price is supported, so ERP-side price structure decides what can be published
What will your dealers actually use?
Ask them, with a specific question rather than a general one. The general question, would you use an online portal, gets a polite yes from everyone and predicts nothing.
The specific question is: when you place an order with us, what do you have open in front of you? A dealer working from your spreadsheet and their own inventory system is a candidate for a structured upload. A dealer who phones because they want to talk to a person about substitutions will keep phoning regardless of what you build, and that is not a failure of the portal.
Then check the incentive. If your dealers get better service, or faster pricing, or their own order history by using the portal, they will use it. If the portal exists to save your order desk time and offers the dealer nothing, adoption stalls at the dealers who like you most. Build one thing into the first release that the dealer wants and cannot get by phoning, and stock visibility or order status is usually the cheapest such thing.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Can we just put the price list behind a login and stop there?
- Yes, and for a meaningful number of manufacturers that is the right end state for a year or more. A dated, login-gated price list produced from the ERP removes the version problem, which is the complaint dealers actually raise, and it costs a fraction of a transactional portal. It does not remove order entry work, so if your tally shows the cost is in keying rather than in pricing confusion, this will not be enough on its own.
- Our prices only exist in the spreadsheet. Where do we start?
- With the pricing, as its own project. Moving dealer prices into Acumatica or Cin7 in a structure the ERP can calculate from is the work that makes every later option possible, including a portal, punchout, EDI and even a better spreadsheet. Prove it by producing your price book from the ERP for two consecutive cycles before you commit to a commerce platform, because that test also tells you whether your pricing rules are expressible at all.
- How many dealers do you need before a portal pays for itself?
- Dealer count is the wrong variable and it is the one everyone reaches for. What decides it is change latency multiplied by how often prices change, plus the share of orders being repriced at entry. A manufacturer with 15 dealers and monthly price changes has a stronger case than one with 200 dealers on a fixed annual price book. Measure those two things on your own numbers rather than looking for a threshold.
- Will a portal upset the reps who own these dealer relationships?
- It will if the portal is presented as a replacement for them, and that is the most common reason dealer portals go unused. Settle the commission and account ownership question before launch, give reps the ability to place and see orders on behalf of their dealers, and make the portal the thing that removes their price-lookup work rather than their income. Adoption is a compensation design problem at least as much as a software problem.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.