The problem
The client distributes electronic components to business buyers, and every part is identified by manufacturer and part number. Two prices matter for each item: the base selling price, which has to keep pace with supplier cost, and the online price, which has to stay competitive with other sellers of the same part. Both were maintained by hand once a month.
Staff compared each item's supplier cost with last month's, one item at a time, to find increases.
Every cost increase meant recalculating the selling price from that item's markup by hand.
Competitor prices were looked up part by part to keep online prices competitive.
A cost increase that slipped through quietly ate into margin until someone noticed.
At catalog scale the work was slow, and the same rules were not applied the same way every month.
What we built
We kept it deterministic. Pricing decisions with money on the line need to be predictable and explainable, so the engine runs two plain rules, not a model. Once a month it reads the catalog from the ERP, compares this month's costs with its own snapshot of last month's, checks live competitor offers for eligible parts, and applies only the changes that pass every guard. Anything that needs judgment goes to a person, with the reason attached.
Monthly run
Sample rows
| Part | What changed | Rule | Decision | Status |
|---|---|---|---|---|
| Part A-1001 | Supplier cost up 8% | Margin | Base price raised at the item's markup | Updated |
| Part A-1002 | Lower in-stock offer found | Competitor | Online price set just under it, above the floor | Updated |
| Part A-1003 | Supplier cost down 5% | Margin | Held for review, not cut | Flagged |
| Part A-1004 | Rival price below the margin floor | Competitor | Not matched | Flagged |
| Part A-1005 | No change since last month | Both | Already correct | Skipped |
| Part A-1006 | Markup missing in the ERP | Margin | Not priced | Flagged |
Margin rule
When a supplier's cost rises, the base price is recalculated from that item's own markup, so the margin holds
Competitor rule
Finds the lowest in-stock, single-unit offer for the same part and undercuts it by a set percentage, but only if the result stays above a minimum margin over cost
Cost memory
A month-by-month snapshot of costs, so increases are measured against last month rather than guessed
Exception queue
Cost decreases, missing data and matches that would break the margin floor are listed for review instead of priced
ERP write-back
Approved prices go straight into the ERP, and items that are already priced correctly are skipped
Run reports
A summary, a list of updates and a list of exceptions emailed to the pricing team after every run
How it works
From trigger to result.
How the system works
8 stages
01Monthly schedule
LogicRuns once a month, unattended, and never twice for the same month.
02ERP catalog
TriggerActive items, current costs and price levels.
03Last month's costs
DataA snapshot the engine keeps, so increases are measured, not guessed.
04Margin rule
LogicCost up: new base price from the item's own markup.
05Competitor offers
TriggerLowest in-stock, single-unit price for the same part.
06Margin floor check
LogicUndercut only if the price stays above the floor.
07Exceptions
PersonCost drops, missing data and floor breaches go to a person.
08Write-back and reports
ResultApproved prices written to the ERP. Summary, updates and exceptions emailed.
Rules-based by design. There is no AI in the pricing decision, so every change can be traced back to a rule and a number.
Our approach
How we worked.
Discovery
Mapped how the pricing team set prices by hand and turned it into two written rules with clear limits.
Guards first
Agreed what must never happen automatically, such as cutting a price because a cost fell, or pricing below the margin floor.
Build
Connected the ERP catalog, the month-over-month cost snapshot and the competitor data source, with rate limits and one-at-a-time ERP writes.
Baseline
The first run recorded costs without changing a single price, so every later run compared like with like.
Run
An unattended monthly schedule that can never apply the same month twice, with reports to the team after each run.
The outcome
What changed.
The whole active catalog was checked every month without anyone opening a spreadsheet.
Supplier cost increases reached the selling price in the same monthly run, at each item's own markup.
Online prices followed the market down only as far as the margin floor allowed.
Cost drops and unusual cases reached a person with the reason attached, instead of being applied silently.
Every run left an audit trail: what changed, what was skipped and why.
Questions
What people ask.
Can NetSuite prices update automatically when supplier costs change?
Yes, with an integration. The engine reads item costs and price levels from NetSuite, compares them with last month's costs, recalculates the selling price from each item's markup when a cost rises, and writes the approved price back.
How do you stop automated repricing from eroding margin?
With guards that run before any price is written. A competitor price is only matched if the result stays above a minimum margin over cost, and a falling cost never cuts a price on its own. Those cases go to a person instead.
Why use rules instead of AI for pricing?
Because every price change has to be explainable. A rule and a number can be checked line by line; a model's output cannot. For repricing against costs and competitor offers, plain rules are faster to audit and safer to trust.
What happens to items the engine cannot price?
They are listed in an exceptions report with the reason, such as missing data, a cost decrease or a competitor price below the margin floor, so the pricing team decides those by hand.
