Building inside your ERP has never been easier. Scripts, workflows and now AI agents let a small team replace tools they used to pay for. Pricing is an obvious candidate. Sometimes it is the right call. Often it is not.
A long thread on r/Netsuite asked which subscriptions people had replaced with their own builds. The answers were a good map of where building works: document capture, dunning, time and expense, a shipping compliance tool one team replaced after paying a lot for something often out of date. One reply summed up the pattern well: the wins were tools wrapping a process that belongs to you and rarely changes shape. The regrets were tools sitting on top of rules that move outside your control.
Pricing has a foot in both camps, which is why the decision is harder than it looks.
The part of pricing worth building
Some pricing logic is yours, stable and simple to state:
- Landed cost from your receipts.
- A minimum margin per category.
- Markups per category and price level.
- Who can approve a discount below the floor.
If that is all your pricing needs, build it. It lives where your data lives, it costs nothing per month, and the rules change once a year. A script and a few custom fields will do the job, and the price list template guide shows the same logic in a spreadsheet.
The part that turns into a second job
The trouble starts when the pricing has to react to things outside the ERP, or learn from what happened:
- Market prices
Competitor prices have to be collected, matched to your parts and kept fresh.
- Learning from outcomes
Which prices won and lost, by segment, updated every week.
- Explaining each price
The reasons on every line, so reps trust and send it.
- Keeping it running
Monitoring, fixing bad data, and handling every ERP upgrade.
Each of these is a moving target. Competitor sites change. Customer behaviour shifts. The ERP's own pricing model changes, as NetSuite's did in 2026. A built tool that handles these needs an owner, and that owner is now maintaining a pricing product instead of doing their real job.
Build the rules you own. Think hard before building the parts that have to learn and keep up.
Questions to decide it
- Does your pricing need anything the ERP does not already hold? If not, build.
- Who will own it in two years, when the person who wrote it has moved on?
- What does a wrong price cost you, and how fast would a built tool tell you it was wrong?
- Would you rather spend the next six months building pricing, or using it?
A middle path
Many distributors do both. They keep the stable rules inside the ERP, where they belong: costs, floors, price levels, contracts. They buy the part that learns, watches the market and explains each price, and let it write its prices back into the ERP fields the team already uses. The ERP stays the system of record. Nobody has to become a pricing software team.
That split, rules you own in the ERP and decisions from a tool that learns, is how we built Elastly to work. But the questions above are worth answering honestly before talking to any vendor, us included.