Field-level comparisons break when business rules change. There is a better approach.
When a vendor changes a rate on a purchase order that has already been partially received, how does your system detect it? Most custom solutions compare the current rate field to a stored "original rate" field. This works until it does not.
We learned this the hard way on a complex B2B engagement, and the architectural revision we made has since become a standard pattern in our practice. The shift: stop comparing fields and start comparing committed values.
The intuitive approach is straightforward. When a purchase order is created, store the original rate. On every subsequent edit, compare the current rate to the original. If they differ, flag the change.
This breaks in several real-world scenarios. If the rate field is not the only factor affecting the line value (consider quantity-based discounts, currency conversion, or promotional adjustments), then a rate comparison misses changes that affect the financial outcome. If the business later adds a new pricing mechanism, the comparison logic needs to be updated. And critically, if a rate changes and then changes back within the same editing session, the field comparison shows no change even though an intermediate state existed.
The deeper problem is that field-level comparison is tightly coupled to the data model. Any change to how pricing works requires a corresponding change to the detection logic. This is fragile by design.
Instead of asking "did the rate field change?", ask "did the committed financial value of this line change?"
The committed value is the product of the rate and the quantity that has been received or billed. This is the number that matters to finance and to auditors. It represents the actual financial exposure at the point of commitment.
When a purchase order line is edited, we calculate the effective committed value (Rate multiplied by Quantity Received) and compare it to the previously recorded committed value. If the delta is non-zero, the system captures the change, records the variance and triggers the appropriate control response: an adjustment journal, a notification to finance or an approval workflow, depending on the materiality of the delta.
The delta-based approach is field-agnostic. It does not care whether the financial change came from a rate adjustment, a quantity correction, a discount modification, or a currency revaluation. It measures the outcome, not the input. This means the detection logic does not need to be updated when the business adds new pricing mechanisms.
It is also net-zero-proof. If a rate increases on one line and decreases on another by the same amount, a header-level comparison would show no change. The delta-based approach captures both line-level movements independently, preserving the audit trail that shows what actually happened.
Finally, it aligns with how auditors think. External auditors do not ask "did the rate field change?" They ask "what is the financial impact of changes made to committed transactions?" The delta-based model answers their actual question directly.
The model requires a custom record that stores committed value snapshots at each significant lifecycle event (receipt, bill, approval). Each snapshot records the line ID, the committed value at that point and the transaction event that triggered the snapshot.
Detection runs as a User Event on the afterSubmit entry point of the purchase order. It compares the current committed value to the most recent snapshot and, if a delta exists, creates a new snapshot record and triggers the control response.
One critical design rule: lifecycle irreversibility. Once a purchase order line has been received, the committed value snapshot cannot be modified retroactively. Any subsequent change creates a new delta record rather than updating the original. This preserves the complete history of changes for audit purposes.
Teams that attempt this model usually hit the same three problems. Each one can invalidate the audit trail if not handled explicitly.
If two users edit the same purchase order within seconds of each other, both User Event scripts can read the same "current snapshot" and each create their own delta against it. The result is two deltas that both claim to start from state X but together produce an invalid transition.
The fix is a sequence number on the snapshot record and an optimistic concurrency check. Before writing a new snapshot, re-read the latest snapshot for the line and confirm its sequence number matches what was read at the start of the operation. If it does not, the script re-runs its delta calculation against the newer snapshot. This adds two search calls but eliminates the entire class of concurrency-related audit gaps.
A purchase order can be modified via the PO form, via a vendor bill adjustment that triggers retroactive rate change, via a credit memo, via a return authorisation and via Map/Reduce scripts running nightly reconciliation. Each of these has a legitimate claim to update the committed value. If your User Event only fires on the PO record, you miss all the other pathways.
The production-grade answer is a central commitment recalculation service implemented as a Workflow Action Script that any transaction in the chain can invoke. The service takes a line reference, recalculates the committed value from scratch by querying all related transactions and writes a new snapshot if the value has changed. User Events, workflows and scheduled scripts all route through the same service, guaranteeing consistency.
If a user edits a PO, increases Line 1 by £1,000 and decreases Line 2 by £1,000, a naive header-level check would show zero total change. But the financial exposure has shifted between lines, which matters for project accounting, inventory allocation and class-based reporting.
Snapshots must therefore be line-level, not header-level. And the control response logic must evaluate absolute delta (sum of absolute line deltas) not net delta (signed sum). A net-zero PO with a £50,000 absolute delta is a material event that requires the same control response as a £50,000 net increase.
The lesson extends beyond purchase orders. Any time you are building financial controls in NetSuite, ask yourself: am I detecting field changes or value changes? If the answer is fields, consider whether a delta-based approach would be more resilient. Controls that measure outcomes rather than inputs are inherently more robust because they survive changes to the business logic that produces those outcomes.
Building financial controls in NetSuite? We can help architect them.
Book a Free Consultation