Pricing operations: a discrepancy queue that unblocks orders the same day

The situation

Prices drift. A quote is agreed in the CRM, a condition record changes in the ERP, a discount is applied on one side and not the other — and the order blocks. In a business shipping thousands of lines a day, this is not an exception to be handled, it is a steady daily volume.

The volume was being handled in spreadsheets: export both sides, compare, hunt down the difference, ask someone to correct it, hope it took. Orders sat blocked while that ran, and the people doing it were commercial staff, not data staff.

What was built

The comparison stopped being an exercise and became a queue — a permanent, always-current list of every line where the two systems disagree.

• Continuous comparison of pricing between CRM and ERP, surfacing each difference with its magnitude and direction.
• A worklist ordered by impact, so the expensive discrepancies are handled first rather than whichever surfaced first.
• A two-step repricing flow: a proposed correction, then an approval — one person can move quickly, but nobody reprices unilaterally.
• Approved corrections written back into SAP directly, so the fix lands where the order actually blocks.
• Blocked-order resolution in the same screen, closing the loop between the discrepancy and the consequence.

Why two steps and not one

A single-click reprice would be faster and would have been wrong. Prices are commercial commitments; a system that lets one person change one silently is a system that will eventually be used that way. The two-step flow costs a few seconds per correction and buys an approval record for every price that moved.

What changed

231 discrepancies a day are worked rather than accumulated, blocked orders clear the same day, and every correction carries who proposed it and who approved it.

The systems and the numbers are real. The client is withheld here by default.