A sales leader at one of the largest consumer companies in the world described the mechanism in four sentences.
They agree a price with a retailer and update it in their system. The retailer never updates theirs. The invoice goes out at the new price and the payment comes back at the old one. Sometimes it does not come back at all.
The internal name for it is a short pay. Multiply it across thousands of products and systems that do not talk to each other, and her summary of the cause was direct: all of these issues because our systems are not synchronized.
This is a company that can afford any tool on the market. The money leaks through a gap nobody can see.
What a short pay is and why it hides
A short pay is a payment that arrives for less than the invoiced amount, with the difference taken as a deduction by the paying party. The commercial reasons vary: a price discrepancy, a promotional allowance, a delivery shortage, damaged goods, a disputed charge.
The price discrepancy version is the one that compounds silently, and it hides because it is correct in both systems at once.
The supplier's system holds the newly agreed price, so the invoice is right. The retailer's system holds the previous price, so the payment is right. Neither party has an error to detect. The gap exists only in the comparison between two records that no single system contains, and the comparison is performed by a person.
| Where it is visible | What it looks like |
|---|---|
| Supplier's order system | A correct invoice |
| Retailer's payable system | A correct payment |
| Supplier's bank reconciliation | A small unexplained difference |
| Supplier's receivables ageing | A residual balance that gets written off |
| Anyone's dashboard | Nothing |
The fourth row is where the loss finally settles. A residual balance too small to chase individually, written off in aggregate at period end, repeated across thousands of line items.
Where the money leaks
Five points in order to cash, and what each one can detect
| Point | Holds the agreed price | Holds the paid price | Can detect the gap |
|---|---|---|---|
| Commercial negotiation | Yes | No | No |
| Order entry | Yes | No | No |
| Invoicing | Yes | No | No |
| Cash application | No | Yes | Only by comparison |
| Dispute and deduction handling | No | Yes | Yes, case by case |
Only the bottom two rows see both numbers, and only the last one investigates. Everything upstream is working correctly on its own terms.
Why the usual controls do not catch it
Four reasons, and the first is the structural one.
The control is a three-way match that does not include the agreement
Standard order-to-cash controls compare the order, the receipt and the invoice. All three originate in the supplier's own systems and all three carry the same price, so the match passes. The document that would reveal the discrepancy is the counterparty's price record, which the supplier does not have.
Each instance is below the threshold for investigation
A difference of a few percent on one line item does not justify a person's time. The decision to let it go is individually rational and the aggregate is substantial, and nothing in the process ever sees the aggregate.
The work is absorbed rather than reported
Someone in billing or collections handles these, every week, by checking a price against an email or a contract and deciding whether to chase. That effort is real and it appears in no system as a cost, because the person's time is not booked against the activity.
The root cause sits with the counterparty
Fixing the discrepancy at source requires the retailer to update their record, which the supplier cannot do. That makes the problem feel unfixable, so the handling becomes permanent and the cost becomes a condition.
Data quality standards are the relevant reference here rather than financial controls. The ISO 8000 series addresses data quality including the exchange of master data between organizations, which is precisely the failure: two parties holding the same commercial fact in different states with no mechanism to reconcile. ISO 9001 requires control of nonconforming outputs, and a short pay is a nonconformity that both parties' systems classify as conforming.
How to find the size of it
The aggregate is the number that changes the decision, and it has to be assembled from three places.
| Source | What it gives | What it misses |
|---|---|---|
| Receivables ageing and write-offs | The monetary residue | Why each one happened |
| Deduction and dispute records | Reason codes where they exist | The ones never disputed |
| The people handling them | The reason, the frequency, the effort | Nothing, this is the complete view |
The third row is the one organizations skip, and it is the only source that supplies the two numbers that matter: how often a discrepancy is absorbed without a dispute, and how much time the handling consumes per week.
Five steps.
1. Ask the people in billing and collections what they do with a small difference
Not a process question. What happens when a payment arrives short by a small amount, what do you check, how long does it take, and how often do you decide to let it go. The answers are specific and immediate.
2. Count the absorbed cases, not the disputed ones
Disputes are recorded. Absorbed differences are the invisible majority and the frequency has to come from the people absorbing them.
3. Attach the handling effort to a named activity
Hours per week spent reconciling price differences, in a named team. This is the operating cost of the gap, separate from the revenue lost.
4. Separate the causes
Price discrepancy, promotional allowance, shortage, damage, dispute. They have different fixes and they are frequently reported as one deduction category.
5. Quantify the aggregate on the price-discrepancy subset
Monetary residue plus handling hours, for that one cause. This is the figure that justifies a master data intervention, and it is usually the first time anyone has seen it.
What actually reduces it
Four interventions, in order of return.
A price change confirmation step with the counterparty. The cheapest fix and the least used. A confirmation that the new price has been applied on their side, before the first invoice at that price goes out. It moves the detection from cash application to the agreement itself.
Flagging the first invoice after any price change. Price changes are known events. Marking the first invoice issued after one, and checking its payment specifically, catches the discrepancy on instance one instead of instance forty.
A tolerance policy with a reporting floor. Differences below a threshold are still absorbed, and they get recorded with a reason code so the aggregate exists. The write-off continues and the number becomes visible.
Master data exchange where the relationship justifies it. For the largest counterparties, a mechanism for keeping price records synchronized. Expensive, effective, and only worth it once the aggregate from the previous steps is known.
| Intervention | Cost | Catches it at |
|---|---|---|
| Price change confirmation | Low | The agreement |
| Flag first invoice after a change | Low | First occurrence |
| Tolerance policy with reason codes | Low | Still absorbed, now counted |
| Master data synchronization | High | Prevented |
The first three cost almost nothing and none of them is possible without knowing which price changes happened and who handles the residue, which is operational knowledge rather than system data.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform, and the short pay problem is a good illustration of why system data is insufficient. Both systems are correct, the discrepancy exists only in a comparison a person performs, and the effort that person spends is booked nowhere.
Discovery Cycles run AI-led interviews with the people performing the work, asking what they did, where they waited, what they corrected and how often. In a billing or collections function those questions produce the absorbed-case frequency, the handling time per case and the reason behind each category, which is the content no reconciliation report contains.
The Process Library records the handling as it is actually performed, including the checks done against emails and contracts that leave no system trace. The Insights Dashboard attaches hours to the finding with traceability to the inputs behind it, which is what turns a residual write-off into an attributable operating cost. The Initiatives Dashboard carries the intervention forward with a named owner, which matters here because the cost sits in finance and the fix sits in commercial.
At PedidosYa, a cycle covering 15 markets and more than 14 interviews produced 31 findings across an operation working with 25,000 partners. Two of the specifics are the same shape as the problem in this piece: roughly four to five hours a week absorbed by billing work, and close to forty hours a month going into reporting. A partner network at that scale is where price and term discrepancies multiply, and a weekly hours figure on a named billing activity is what makes the leakage visible as a cost rather than as a write-off. These figures describe one engagement and they are evidence rather than a guarantee.
The question worth asking any finance operation: how many hours a week does your team spend reconciling price differences, and how many of those differences are absorbed without ever being disputed?
Common mistakes
Treating short pays as a collections problem. Collections handles the residue. The cause is a master data gap with the counterparty and the fix sits in commercial and order management.
Reporting all deductions as one category. Price discrepancies, promotional allowances, shortages and damages have different fixes, and aggregating them hides which one dominates.
Counting only disputed cases. The absorbed differences are the majority and they are invisible by definition, so the recorded dispute volume understates the problem structurally.
Ignoring the handling cost. The revenue loss gets attention and the hours spent reconciling do not, even though the hours are frequently the larger number.
Relying on the three-way match. Order, receipt and invoice all originate in the same systems and carry the same price, so the match confirms internal consistency and cannot see the counterparty's record.
Going straight to master data integration. It is the right answer for the largest relationships and it is expensive, and the case for it depends on an aggregate figure that the cheap interventions produce first.
Not flagging the first invoice after a price change. Price changes are known events, and checking the first payment after one converts a recurring loss into a single caught instance.
FAQ
What is a short pay?
A payment that arrives for less than the invoiced amount, with the paying party taking the difference as a deduction. Causes include price discrepancies, promotional allowances, delivery shortages, damaged goods and disputed charges, and they are frequently reported together as one deduction category.
Why do price-discrepancy short pays go undetected?
Because both systems are correct. The supplier's system holds the newly agreed price so the invoice is right, and the counterparty's system holds the previous price so the payment is right. The gap exists only in a comparison that no single system performs.
Why don't standard order-to-cash controls catch it?
The three-way match compares the order, the receipt and the invoice, all of which originate in the supplier's own systems and carry the same price. The record that would reveal the discrepancy belongs to the counterparty, and the supplier does not have it.
How do you quantify the total loss?
Combine the monetary residue from receivables write-offs with the handling effort, and get the frequency of absorbed cases from the people handling them rather than from dispute records. Absorbed differences are the invisible majority, so recorded disputes understate the problem by design.
What is the cheapest effective fix?
A confirmation step with the counterparty that a new price has been applied on their side before the first invoice at that price is issued, combined with flagging the first invoice after any price change and checking its payment specifically. Both move detection from the write-off to the first occurrence.
The gap is between the systems, so look between them
Two parties, two correct records, one commercial fact held in different states. Nothing in either organization's systems is wrong, which is why a dashboard built on either one shows nothing.
What reveals it is the person in billing who checks a price against an email every week and decides whether the difference is worth chasing. That handling is the evidence, the frequency, and the operating cost all at once, and it is recorded nowhere until somebody asks.
See it. Fix it. Win it.