Multi-processor residual reconciliation: one book from several reports
Residuals from several processors do not add up on their own. Each processor uses its own layout, its own definition of profit, its own merchant identifiers and its own delivery date, and a merchant that moved processors appears in two files. Reconciling them means loading each file untouched, mapping each to the same handful of fields, tying each processor's total back to its own file, matching merchants to agents by processor and merchant ID, then checking the combined book: merchant count against last month, every merchant with profit assigned, shares summing to 100%, and agents plus overrides plus house equal to what came in. A processor's portal shows only that processor, so the combined view has to be built outside it.
An ISO with one processor has a spreadsheet problem. An ISO with three has a reconciliation problem, and it is a different kind of work. The arithmetic on each file is easy. The difficulty is that the files describe the same business in three languages, and the month is only right when all three agree with each other and with what you paid.
This guide covers what goes wrong when residual reports from several processors are combined, the method that produces one reliable month, and the checks that catch the errors before agents see them.
Why the files do not add up on their own
| What differs | What it looks like | What it breaks |
|---|---|---|
| Layout | One processor sends a year-to-date workbook with a tab per month, another a flat CSV, a third a PDF someone has to re-key | Anything that assumes one shape |
| The profit column | GPR, Net Revenue, Partner Revenue Share, Total Profit, Residual. Some are before the processor's split, some after | Paying agents on the wrong base for one processor |
| Rows per merchant | One row per merchant on one file, one row per device or per app on another | Counting rows as merchants overstates the book |
| Merchant identity | Each processor has its own merchant number, and a merchant that moved processors has two | Double-counting a moved merchant, or losing it |
| Timing | Files arrive on different days, often a week apart | Closing the month before the last file, or reopening it after |
| Currency | A Canadian processor pays in CAD, a US one in USD | Adding the two as if they were the same |
| Income types | Processing, equipment rental, software and app revenue arrive in separate files from some processors and in one from others | Paying the same percentage on income that should be paid differently |
Any one of these is manageable. An office with three processors has all seven at once, every month.
Why the processor's portal is not the answer
Every large processor offers a portal where you can see your residuals from that processor. They are useful for checking a merchant. They cannot reconcile the book, for a simple reason: each one shows one processor. Your agents do not sell for one processor, your merchants are not all on one, and your house margin is the sum across all of them. An agent's statement built from one portal is missing every merchant on the others.
The combined view has to be built outside the portals, from the files, in one place that treats every processor the same way.
The method
1. Load every file untouched
Each processor's file is kept exactly as it arrived, with its date. Cleaning and summing happen in a separate step that can be re-run. The moment someone edits a file by hand, that month can no longer be reproduced, and reconciliation depends on reproducing it.
2. Map each file to the same fields
Whatever the processor calls them, every file has to yield the same handful of fields per merchant: processor, merchant ID, merchant name, period, income type, and Total Profit. The mapping is done once per file type and written down, including which column is the profit and whether it is before or after the processor's split. When a processor changes its layout, the mapping changes and the change is recorded. Column-by-column detail for one processor is in How to read a First Data residual report.
3. Sum multi-row files per merchant
Rental and app files with several rows per merchant are added up by merchant ID before anything else happens. The number of unique merchant IDs, not rows, is the number of merchants.
4. Tie each processor's total back to its own file
Before combining anything, the Total Profit you have loaded for each processor should equal the total on the processor's own file, to the cent. If it does not, the mapping or the summing is wrong, and nothing downstream can be trusted until it is fixed. This is the single most valuable check in the whole process, and it is done per processor, not on the combined book.
5. Match merchants to agents by processor and merchant ID
An agent owns a merchant on a processor. The same merchant on a second processor is a second assignment, even when the name is the same. Matching on name is how a moved merchant gets paid twice, or a merchant with a common name gets paid to the wrong agent. Where a merchant genuinely moved, the old assignment ends on a date and the new one starts.
6. Convert currency per period, and keep the original
If processors pay in different currencies, convert to one reporting currency using the rate for that month, and keep the original amount alongside. Agents paid in the processor's currency should see that currency on their statement. The Canadian case is covered in ISO residuals in Canada.
7. Apply agreements by income type
Processing, equipment and software income are often paid at different percentages. Each file, or each part of a file, carries its income type through to the calculation so the right percentage applies. The structures are in ISO commission split structures explained.
8. Close the month only when every file is in
A month with two processors loaded and one missing is not a month. Either wait for the last file, or publish per processor and say so to the agents. What does not work is publishing the month, then reopening it when the late file arrives, because agents have already seen a number that is about to change.
The checks, in order
Run these before anyone is paid, the same way every month.
- The period on every file is the month being closed. A year-to-date workbook makes this an easy mistake.
- Each processor's loaded Total Profit equals that processor's file total. Per processor, to the cent.
- Unique merchant count per processor is close to last month's. A large move is a data question before it is a business question.
- Every merchant with profit has an agent, on every processor.
- A merchant appearing on two processors is either two real accounts or a move, and if a move, only one is active this month.
- Shares on shared merchants sum to 100%.
- Each agent's total against last month, with a known reason for any large move. A merchant that moved processors is the usual explanation for a swing that is not attrition.
- Agents paid, plus overrides, plus house, equals the combined Total Profit after deductions. The book balances or it does not.
A month that passes all eight is a month that can be defended to an agent, to a buyer and to an auditor.
What a reconciled book lets you see
Once every processor is in one place with the same fields, questions that were impossible become routine.
- Which processor makes money. Profit per merchant, by processor, after that processor's fees, on the same basis. Covered in Which payment processor pays best?.
- Which merchants are fading, wherever they process. Attrition is only visible across months, and only complete across processors.
- How concentrated the book is, by merchant and by agent, across everything rather than within one portal.
- What the book is worth. A buyer prices the whole book, and a reconciled twelve months across every processor is what they will ask for. The merchant portfolio valuation calculator shows how much the answer depends on numbers you can only get this way.
Frequently asked questions
How do I combine residual reports from multiple processors? Load each file untouched, map each to the same fields (processor, merchant ID, period, income type, Total Profit), sum multi-row files per merchant, tie each processor's total back to its own file, then match merchants to agents by processor and merchant ID. Only then combine, and run the checks above before paying anyone.
Why do my residual totals not match across processors? Usually because the profit columns are not the same thing. One processor reports profit before its split and another after, or one file has several rows per merchant and was counted by row. Tie each processor's loaded total to its own file first, and the mismatch will be on one side.
Can I use my processor's portal to pay agents? Only for merchants on that processor. An agent with merchants on two processors needs a statement built from both, and the portals do not talk to each other. The combined statement has to be built outside them.
What happens when a merchant moves from one processor to another? It appears in both files, possibly in the same month. Treat it as two assignments, end the old one on a date and start the new one, and check that only one is active in a given month. Matching on name instead of processor plus merchant ID is how moved merchants get paid twice.
When should I close the month if processor files arrive on different days? When the last file is in. Publishing early and reopening the month when a late file arrives changes numbers agents have already seen. If one processor is always late, tell agents the publish date is set by that file.
How does SplitRun reconcile residuals across processors? SplitRun holds each processor as its own data source with its own layout, currency and revenue flow, reads each file as it arrives and keeps the original, sums multi-row files per merchant, converts currency per period, applies agreements by income type, and produces one statement per agent across every processor. The dashboard then shows profit by processor, fading merchants and concentration on the combined book. See Add a data source, Upload a report and Verifying numbers.
See what your agents would receive each month.
View the sample report