An electronics maker checks every serial number its partners report
An electronics maker relied on its channel partners to report what they sold. Thirteen checks on serial numbers, returns, customers and vendors showed where the reports and the records disagreed.
From our own project and product work. Client names and identifying details are removed, and some figures are rounded.
The situation
An electronics maker sells most of its products through distributors and resellers. Partners report each sale back (the sell-out), and those reports drive incentives, returns and stock planning. The business control team wanted to know where the partner reports, the invoices and the system records disagreed, across sales, returns, purchasing and the activation of each device.
What we looked at
- Sales invoices, partner sell-out and sell-through reports, by serial number
- The date each device was first switched on and activated
- Sales returns, including dead-on-arrival cases
- Customer and vendor masters, credit limits and payment terms
- Purchase orders and the approval limits behind them
The 13 checks
| Check | What it flags |
|---|---|
| Invalid sell-out | Duplicate invoices, repeated serial numbers and invoice numbers out of sequence |
| One serial, many transactions | The same device reported more than once |
| Serial tracking | A device whose invoice, sell-out and sell-through records disagree |
| Sell-out against activation | Devices activated long before or long after the reported sale |
| Dead on arrival | Returns still pending, so sales and returns are both misstated |
| Sales returns | Returns at a different price, straight after the sale, with no original sale, very old, or repeated |
| Duplicate customers | The same customer under two codes, matched on name, address, tax ID, email and phone |
| Credit limits and terms | Customers with more than one limit or term, and limits exceeded |
| Split purchase orders | Orders split to stay under an approval limit |
| Payment terms | Order terms that differ from the vendor master |
| Price differences | The same material bought at different prices within 5, 10 or 15 days |
| Vendor master | Duplicate, invalid and dormant vendors |
| Service records | The customer on the service record is not the customer on the sale, checked against the company and tax registries |
What happened
The checks ran in Python on the full data, not a sample. Each exception list went to the business control team, who discussed the significant ones with the business and fed back what was genuine and what had an explanation. We tuned the rules after each round, so later lists were shorter and more useful.
The serial-number and activation checks found gaps that standard reports could not show, because they join records that normally sit in separate systems.
What changed
- From partner reports to device-level evidence. Each reported sale is checked against the full history of its serial number.
- From one-off reviews to a reusable set. The 13 rules run again each cycle and can be extended.
- From master data assumed clean to master data tested. Duplicate and invalid customers and vendors now surface as exceptions.
Products and services
CompliBear runs checks like these on every transaction, every day. See continuous controls monitoring and revenue leakage.