Almost every fintech finance and payment-ops team verifies its payment provider charges in a spreadsheet. It is the obvious tool, it is already open, and it works fine the first month. Then volume grows, the contract changes, the analyst who built it goes on leave, and the same spreadsheet that was supposed to catch overcharges quietly becomes the reason they get missed. The failure is predictable, and it shows up the same three ways every time.
- Spreadsheets are the default tool for reconciling payment service provider (PSP) invoices and the wrong one. They fail in three structural ways as a platform scales.
- Data volume limits: PSP transaction data outgrows what a spreadsheet can hold or recalculate, so teams resort to sampling, and sampling is not verification.
- Formula drift: contract logic encoded in nested formulas silently diverges from the contract over time. Field research finds around 88 percent of operational spreadsheets contain errors, and reviewers catch only about 60 percent of the errors that are there.
- Key-person dependency: the model lives in one analyst's head, which is an operational risk and a control weakness auditors flag.
- Even a flawless spreadsheet cannot do the job, because it has no link back to the source transaction and contract clause, and it runs point-in-time instead of continuously.
- The fix is not a better spreadsheet. It is a system that prices every transaction against the contract automatically and attaches evidence to every discrepancy.
Short answer
The problem with reconciling PSP invoices in spreadsheets is that the work is a per-transaction, contract-conditional, continuous problem and a spreadsheet is none of those things. It breaks in three predictable ways: it cannot hold or recalculate real transaction volume, so checking degrades into sampling; the formulas that encode contract logic drift away from the contract over time without anyone noticing; and the whole model usually depends on one person who built it. Beyond those, a spreadsheet cannot link a flagged charge back to the transaction and clause that prove it, and it runs once a period rather than continuously, so recoverable errors age out before anyone sees them.
The spreadsheet is not where PSP reconciliation starts going wrong because anyone is careless. The people maintaining these models are usually the most diligent on the team. It goes wrong because the tool is being asked to do something it was never built for, and the gap only becomes visible at scale. Here is exactly where it breaks.
Failure mode one: data volume
A platform processing real cross-border volume generates an enormous number of line-level events every period. Payins, payouts, FX conversions, settlement deductions, and fee lines across several providers and several corridors add up to hundreds of thousands of rows a month, and for larger books, millions.
Spreadsheets have hard ceilings. A single Excel worksheet stops at 1,048,576 rows. Google Sheets caps a whole workbook at 10 million cells, which a wide reconciliation table with twenty columns exhausts at around 500,000 rows. One busy corridor in one month can reach those limits on its own.
The ceiling is not even the real problem. Long before a file hits its row limit it becomes unusable. Every edit triggers a recalculation of hundreds of thousands of lookup formulas, so the file takes minutes to open, freezes on a keystroke, and corrupts often enough that someone keeps a backup named with yesterday's date. The team's response is rational and quietly fatal: they stop checking everything and start checking a sample.
Sampling is where verification dies. Fee leakage does not distribute evenly. It hides in a specific tier on a specific corridor in a specific contract version, and it is precisely the kind of thing a five percent sample is built to miss. Worse, recovery requires the specific disputed transaction, not a representative one. You cannot dispute a charge you sampled past. A spreadsheet at scale forces a choice between a file that does not open and a check that does not check, and most teams end up with both.
Failure mode two: formula drift
A PSP contract is conditional logic. It says one rate applies up to a volume band and another above it, that FX carries a spread of so many basis points over a reference rate, that a minimum applies unless transactional fees clear it, that a charge is valid only inside a billing window. Encoding that in a spreadsheet means nested IF statements, lookup tables, and chained formulas. On the day it is built, it is correct.
Then it drifts. Someone inserts a row and a SUM range no longer reaches it. Someone hardcodes a value "just for this month" and it is still there a year later. A tier threshold changes in the signed contract and the formula does not, because the contract lives in a Drive folder and the formula lives in a tab and nothing connects them. The FX reference rate gets pasted in by hand and someone grabs the wrong day. Next month's workbook is copied from this month's, so it inherits every latent error and adds a few.
Nothing flags any of this, because a spreadsheet has no test suite. The output still renders as a clean number, so it still gets trusted. And the base rates here are not comforting. Field audits of operational spreadsheets compiled by University of Hawaii researcher Ray Panko have found that roughly 88 percent contain errors, and separate studies show that people reviewing a spreadsheet catch only about 60 percent of the errors actually in it. The tool you are using to catch billing errors is itself error-prone, and the person checking it will, on average, miss two of every five mistakes. A reconciliation model that has drifted from the contract is not the exception. It is the expected state of any spreadsheet that has been in service for more than a couple of quarters.
Failure mode three: key-person dependency
The third failure has nothing to do with rows or formulas. It is that the model lives in one person's head.
One analyst built the workbook. They know which cells are hardcoded, which lookups are fragile, why one column is shaded yellow, and which tab must never be sorted. That knowledge is the documentation. There is no other copy of it. When that person is on leave, out sick, or hands in their notice, verification either stops or carries on blind, and a handover becomes a tense week of "please do not touch the FX tab."
This is not only an operational inconvenience. It is a control weakness, and a visible one. Auditors specifically look for key-person dependency and lack of segregation of duties, and a process where a single analyst's private spreadsheet is the only thing standing between the company and its provider costs is exactly what they flag. For a fintech being diligenced or raising, "our provider-cost verification depends on one person's spreadsheet" is not a sentence anyone wants to say out loud. The function meant to protect the margin runs on a bus factor of one.
The part a better spreadsheet still cannot fix
Suppose you solved all three. Infinite rows, perfectly maintained formulas, full documentation and a trained backup. The spreadsheet still cannot do the actual job, for two reasons that are properties of the tool rather than the build.
It has no provenance. A spreadsheet can show that a charge differs from your estimate, but it cannot hold the underlying transaction, the contract clause that was breached, and the calculated expected figure together in one defensible record. So you can suspect a charge is wrong and you cannot prove it, and an overcharge you cannot prove is not an overcharge you can recover.
And it is point-in-time. The reconciliation runs once at month-end, catches what it catches, and starts from zero next period. Patterns across periods stay invisible, and by the time a first-quarter error surfaces at the year-end close, the contractual window to dispute it has usually closed. The money was real, recoverable, and is now gone, for the single reason that nobody looked in time.
These are not arguments for a tidier workbook. They are the reason the category of work and the category of tool do not match.
The bridge: what actually replaces the spreadsheet
The alternative to a failing spreadsheet is not a bigger spreadsheet. It is a different kind of system, one built for the shape of the problem rather than retrofitted to it.
That system turns each provider contract into executable pricing logic, so the tiers, spreads, minimums, and timing rules become calculations rather than prose in a folder. It prices every transaction against that logic to produce an expected charge, not a sampled estimate but a figure for each event. It compares expected against actual continuously rather than once a month, so discrepancies surface while they are still inside the dispute window. And it attaches the evidence, the transaction, the clause, the expected and actual figures, to every discrepancy, so a finding is recoverable rather than merely suspicious. This is what fintech infrastructure verification means, and it is what platforms such as Bluefyn are built to run.
The bottom line
Reconciling PSP invoices in spreadsheets works exactly until it matters. As volume grows the file stops opening and checking degrades into sampling. As time passes the formulas drift from the contract they were supposed to enforce. And the whole thing rests on one person who happens to know how it works. None of these are failures of effort, and none are fixed by building the spreadsheet more carefully, because the work is per-transaction, contract-conditional, continuous, and evidence-grade, and a spreadsheet is none of those. The teams that scale cleanly stop trying to make the wrong tool work and move the job to a system designed for it.
Frequently asked questions
Why can't I just use a spreadsheet to verify my PSP invoices?
Because verifying PSP invoices means pricing every transaction against the contract that governed it, continuously, with evidence attached. A spreadsheet cannot hold or recalculate that volume, cannot keep its formulas aligned with a changing contract, and cannot link a flagged charge back to the transaction and clause that prove it. It works at small scale and breaks predictably as a platform grows.
How much transaction data can a spreadsheet actually handle?
A single Excel worksheet is limited to 1,048,576 rows, and Google Sheets caps a workbook at 10 million cells, which a wide reconciliation table reaches at roughly 500,000 rows. Well before those limits, recalculation of large lookup formulas makes the file slow, unstable, and prone to corruption, which pushes teams toward sampling instead of full checking.
What is formula drift?
Formula drift is the gradual divergence between the logic encoded in a spreadsheet and the contract it is meant to represent. Inserted rows break ranges, values get hardcoded, tier thresholds change in the contract but not the formula, and copied-forward workbooks inherit old errors. Nothing flags it, so the drifted output keeps getting trusted.
Why is key-person dependency a problem for reconciliation?
When one analyst is the only person who understands the reconciliation model, the process stops or runs blind whenever they are unavailable, and there is no reliable way to audit or hand it over. Beyond the operational risk, it is a control weakness that auditors flag as key-person dependency and a lack of segregation of duties.
Can a better-built spreadsheet fix these problems?
No. Even a perfectly maintained spreadsheet has no provenance linking a discrepancy to its source transaction and contract clause, and it runs point-in-time rather than continuously, so recoverable errors age out before they are found. These are limits of the tool, not the build.
What replaces spreadsheet reconciliation for PSP invoices?
A verification system that converts contracts into executable pricing logic, calculates an expected charge for every transaction, compares it against the actual charge continuously, and attaches evidence to each discrepancy so it can be disputed and recovered. This approach is known as fintech infrastructure verification.
