At the end of the month a demand partner sends its numbers, and they do not match yours. Sometimes the gap is small enough to wave through. Sometimes it is large enough that someone has to explain it, and the explaining tends to take longer than the trading did.
Most discrepancies are not anyone cheating. Two systems counted the same traffic in different ways. The work is finding out which way, and the faster you can do that from your own records, the shorter the conversation.
Why do two honest systems disagree?
They count different events. One side may count a win when the win notice fires, the other when the billing notice fires or when the ad renders. Those can be minutes apart, and some wins never render at all. In video and CTV, where a creative can fail to play after it wins, the gap can be much wider than in display.
They cut the day at different times. If you report in UTC and your partner reports in their local time zone, every daily figure covers a slightly different window. Monthly totals mostly agree, while daily totals look wrong every single day.
They sit on different sides of the fee. One report shows what the buyer paid, the other shows what reached the seller. A large share of “your numbers do not match ours” is gross set against net, with nothing missing.
They convert currency at different moments. A rate taken at bid time and a rate taken at invoice time will drift apart over a month.
And they filter different traffic. Requests removed as invalid traffic on one side may still be counted on the other, and a bid that arrived after your timeout was discarded by you and still counted as a bid by the buyer.
Agree the definitions before the first invoice
Most of the causes above can be settled once, in writing, before money changes hands. Agree which event bills, whether that is the win notice, the billing notice or a render. Agree which time zone the reporting day uses. Agree whether each figure you exchange is gross or net of fees, and say so on every report. Agree the currency and when the conversion happens. And agree what size of gap you both accept without investigation, so small differences do not turn into tickets.
None of this is technical. It is the most effective thing you can do about discrepancies, and it costs one email.
Split the gap before you explain it
A total tells you there is a problem. A breakdown tells you where it is. Split the difference by day, by endpoint, by format and by country, and see whether it is spread evenly or concentrated in one place.
The shape usually points at the cause. A gap that appears every day and vanishes in the monthly total is a time zone problem. A gap that sits almost entirely in video is about what counts as an impression. A gap on a single endpoint that started on a specific day is a change on one side, and the date tells you which change to look at.
If the gap is growing, or stepped up suddenly, it is probably not a definitions problem. Something in the win notice path may have broken, and our guide to setting up an RTB exchange covers the usual failures there, from expired auction records to macros that were never substituted.
What your record needs to hold
You can only split a gap with data at that grain. Daily totals per partner are not enough. You need every request, bid, win and drop, with a reason on every drop, at a level you can filter by partner, endpoint, format and time.
You also need it to be exportable. A partner who can check your numbers line by line will usually accept them, and a partner who is handed a summary will usually send their own. When both sides can look at the same log-level rows, the dispute becomes a lookup.
It helps to watch the same figures before the month ends. Win rate, latency and drop reasons per demand partner show a degrading partner as a row in a report weeks before it shows up as a gap on an invoice.
Where Floxis fits
Floxis is a white-label RTB exchange you run as your own. Every request, bid and drop is logged and exportable, and lands in your reporting about a minute after it happens, with drop reports that show exactly why each request was filtered. Win rate, latency and drop reasons are broken out per demand partner, and the rate you set per endpoint is applied when the bid clears rather than reconciled afterwards.
When a partner disputes a number, it is settled against the log-level record on both sides of the auction. To see that record on your own traffic, book a demo.