Stop Silent Master Edits: Approve Price and BOM Changes

A unit price changes in the customer master. A line on a bill of materials gets swapped for a cheaper part. A vendor record gets a new bank account. Nobody approves these edits, and nobody records why. And every one flows straight into invoices, inventory valuations, production orders, and payment runs.

In most mid-size companies, master data is the soft underbelly of the core business system. The front office guards the bank account. The warehouse guards the keys. But the unit price field, the BOM line, the customer credit limit? Anyone with edit rights can touch them, often without a second person knowing. By the time finance spots the leak at month-end, the damage is already in the ledger.

The fix has three pieces: an approval workflow, a versioned history, and a frozen snapshot of what was approved. Together they move master data from an open door to a controlled, auditable control point. The change-control approval and the versioned audit trail are live today. The automatic writeback of an approved change into the master record itself is on the roadmap, and we will be honest about where that line sits.

Why Silent Master Edits Are an Internal-Control Blind Spot

Internal control frameworks (J-SOX and the broader internal-control discipline) spend enormous energy on transactions. Who approved this purchase order? Who signed this payment? Each transaction gets a review, an approver, a trace.

Master data rarely gets the same attention. The unit price on an invoice is pulled from the sales master, the components on a production order from the BOM, the bank details on a payment run from the vendor master. When the master is wrong, every transaction built on it is wrong, and transaction-level controls never catch it because the transaction itself was generated correctly.

This is why master-data integrity is one of the most cited findings in internal-control reviews. The risk is not a single bad transaction but a quietly corrupted reference that produces a stream of bad transactions, sometimes for months: a unit price lowered by 3 percent across a high-volume line, a BOM line switched to a substitute that fails in the field, a vendor bank account changed to an account nobody recognizes. Each is a one-field edit that can move millions of yen.

The governance gap is simple to name: no second pair of eyes, no reason recorded, no snapshot of before and after. The ERP that runs every transaction with rigor lets the data underneath those transactions be edited in the dark.

What a Master-Change Approval Actually Governs

The fix is to treat a master edit the same way you treat a purchase order or a capital expenditure: a request, routed for approval, with evidence attached. The change types that most need this treatment are the ones that touch money downstream.

Unit price and price-list changes. A standard price revision, a customer-specific special price, or a discount that drops margin below a threshold. These flow into every quote and invoice, and a silent price cut is revenue leakage.

Bill-of-materials and engineering changes. A component swap, a substitute material, a revised routing. These flow into production orders, cost rolls, and inventory valuations, and a silent BOM change can ship the wrong part or distort product cost for an entire period.

Customer and vendor master edits. A new bank account on a vendor record, a credit-limit increase on a customer. These flow into payment runs and order acceptance, and a silent vendor bank-account change is the textbook setup for payment fraud.

Inventory and cost master. A standard cost change, a lot-status override, a valuation adjustment. These flow into the general ledger the moment inventory moves, distorting margin reporting and the balance sheet.

In every case the pattern is identical: one person makes the edit, the edit propagates, and there is no approver, reason, or record. The master-change approval closes that loop by passing the edit through the same discipline as any other business decision.

The Three Pieces: Approval, Version History, Frozen Snapshot

A proper master-change control has three working parts, and each one earns its keep for a different reason.

The approval workflow. A proposed change enters as a request rather than a direct edit, carrying the before value, the proposed after value, and the reason. Routing follows the same rules as any other ringi (internal approval proposals): by role, by department, by amount threshold. A price change above a margin floor might go to the sales manager. A BOM change on a regulated product might require parallel sign-off from engineering and quality. A vendor bank-account change might require parallel review from purchasing, legal, and the information systems team, because the cost of getting it wrong is so high. The approval workflow is built and live today.

The versioned history. Every approved change is stored as a version. You can see that the unit price was 1,200 yen on the first of the month and 1,160 yen after the approved change on the fourteenth, and walk the full lineage of a BOM line over a year with every component swap and its engineering-change note. The version history is built and live today, and it is what makes the master auditable instead of a black box that only shows its current state.

The frozen snapshot. This is the piece that satisfies internal control and J-SOX evidence requirements. When a change is approved, the system freezes a snapshot of exactly what was reviewed: the values, the approver, the timestamp, the reason, and the attached evidence. Months later, when an auditor asks why a price changed and who authorized it, the answer is a single record that cannot be edited after the fact. The frozen snapshot is built and live today, and it is the difference between an internal-control finding and a clean review.

These three together turn a master record from a free-text field into a governed asset: the approval is the gate, the version history the memory, the frozen snapshot the proof.

A Scenario: The Precision Parts Maker in Shizuoka

Consider a precision parts manufacturer in Shizuoka, about 280 staff, supplying automotive and industrial-machinery OEMs from a head office in Tokyo and a factory on the coast. Their product cost is sensitive to component prices and engineering configuration. A single BOM can carry 40 or 50 lines, and a unit-price change on one line can swing the margin on a multi-year OEM contract.

Before they governed master changes, the pattern repeated every quarter. A buyer, under pressure from a supplier, would lower a purchase unit price directly in the vendor master to reflect a negotiated discount. Engineering would swap a component in a BOM to clear a shortage without telling costing. Sales would grant a customer-specific price to close a deal, recorded by whoever had edit rights. Each edit was reasonable in isolation; none had an approver, a reason, or a record.

The symptoms showed up downstream. Month-end margin swung because the cost roll picked up a BOM change nobody in finance knew about. An OEM audit flagged a component substitution because the production records and the engineering master disagreed. A payment went to a vendor bank account changed two weeks earlier, and nobody could say who approved it.

Moving master changes into an approval workflow changed the operating model. A unit-price change now enters as a request naming the customer, product, old price, new price, and reason, routing to the sales manager above a margin floor. A BOM change enters as an engineering-change request routing to engineering and quality in parallel for any product bound for a regulated OEM. A vendor bank-account change requires parallel sign-off from purchasing, legal, and the information systems team before the record can be touched. The version history lets costing trace why product cost moved between quarters, and the frozen snapshot gives the OEM auditor a clean record for every component substitution. The same factory that used to explain margin swings after the fact now governs them before they hit the ledger.

What Is Built Today, and What Is on the Roadmap

Master-data governance is exactly the area where vendors overpromise, so an honest accounting matters.

Built and live today: the master-change approval workflow, the versioned change history, and the frozen snapshot of each approved change. You can route a price, BOM, customer, or vendor change for approval by role and threshold, see the full version lineage of any governed master record, and hand an auditor a frozen record of what was approved, by whom, and why.

On the roadmap, not yet built: automatic writeback of an approved master change into the master record itself. Today, when a master-change request is approved, the approval and snapshot are recorded, and an authorized user then applies the approved change to the live master under the same governance. The fully automatic path, where approval directly updates the master with no manual step, is the next milestone. The registry and change-type definitions are already in place, so adding each writeback handler is contained work, but it is not implemented today.

This changes how you sequence the rollout. You get the approval gate, the version history, and the audit evidence immediately, and full automation of the master-record update as the practice matures. For a company moving from no control at all, that is the right order: prove the discipline first, then automate the last step.

Why This Belongs Inside the ERP, Not Beside It

It is tempting to govern master changes in a standalone spreadsheet or a separate change log. The reason it fails is that a master change only has meaning in the context of the records it affects: a unit-price change matters because it changes the next invoice, a BOM change because it changes the next production order and cost roll. When the approval lives outside the core business system, the connection between the approved change and the affected records is a manual promise, and each handoff is a place the discipline breaks. When the approval, the version history, and the snapshot live inside the same ERP that holds the master data, the governance and the records it protects are never separated.

Frequently Asked Questions

Will approval slow down every price and BOM change?

It changes who is involved, not how long it takes. Most master changes are not urgent, and the few that are (a shortage substitution, a price correction before a billing run) can use fast-track routing. The approval workflow supports delegation, so a traveling manager does not block the change, and watchers let stakeholders follow a change without being approvers. Routine changes take minutes longer and gain a record; risky changes finally get the second pair of eyes they always needed.

We trust our team. Why add approval to master edits?

Trust is not the issue. Segregation of duties is. The person who negotiates a price should not be the only person who records it. The engineer who proposes a component swap should not be the only person who applies it. Internal control is built on the idea that no single person both initiates and completes a sensitive change. Master data has historically escaped this principle because the edits look small. The version history and frozen snapshot exist so that trust is supported by evidence, not substituted for it.

What about the master-record writeback gap?

The approval, the version history, and the frozen snapshot are built. The automatic update of the master record from an approved change is on the roadmap. Today the approved change is applied to the live master by an authorized user under governance, with the approval and snapshot recorded. If a vendor claims their master-change writeback is fully built, ask to see the actual handlers and audit trail.

Does this satisfy J-SOX internal-control evidence?

The frozen snapshot is designed for exactly this. Internal control and J-SOX reviews ask three things on a sensitive change: who initiated it, who approved it, and what was approved. The snapshot captures all three and locks them so they cannot be revised after the fact. Whether your specific auditor signs off depends on your overall control environment, but the snapshot provides the evidence the framework asks for.

Key Takeaway

Master data is where the core business system is most exposed and least governed. A unit price, a BOM line, a vendor bank account: each is a small edit with large downstream consequences. The answer is not to lock the data down so hard that nobody can work, but to give every sensitive master edit an approval, a version history, and a frozen snapshot. The approval and the audit trail are live; the automatic master-record writeback is on the roadmap.

Get Started With Kikan System

If silent master edits have ever moved your margin or your payments, look at Kikan System. The master-change approval workflow, the versioned change history, and the frozen approval snapshot are built to govern price, BOM, customer, and vendor changes inside one ERP, alongside the approval workflows, expense reimbursement, leave applications, purchase orders, inventory with lots, and bill-of-materials modules. You can start on the free plan with up to 2 users, no credit card required. Begin at /#get-started.