TL;DR
- Billing is structurally harder for fintechs and banks: the cost side isn't set by the business, identical transactions carry different prices, and two separate contracts govern every event.
- Visa's US interchange schedule runs 234 separate rate lines, and Regulation II's cap applies only to issuers with $10 billion or more in assets — so identical transactions can cost different amounts by issuer.
- Every transaction is priced twice, once by the provider contract determining cost and once by the client contract determining revenue, and nothing connects the two automatically since they typically sit in separate legal folders.
- Banks recognized this complexity as early as 1986, creating AFP Service Codes and the EDI 822 standard, yet bank-assigned code mappings still run only about 40% accurate today.
Short answer
Billing is harder for fintechs and banks because three things are true at once that are almost never true elsewhere. You do not set the cost side of your own transactions. The same transaction does not carry one price. And every transaction sits under two separate contracts at the same time, one governing what your provider charges you and one governing what you charge your client, each conditional, each versioned, each changing on its own schedule.
Ordinary businesses bill from a price list they control. Payments businesses bill from a structure assembled by card networks, regulators, providers and their own commercial agreements, none of which move together. That is the difference, and every familiar billing failure is downstream of it.
What billing looks like in an ordinary business
Start with the baseline, because the contrast is the whole argument.
A software company sells a subscription. It sets the price. The price sits in a price book the company owns, changes when the company decides to change it, and applies uniformly to every customer on that plan. The cost of delivering the service is real, but it is not a per-transaction cost that arrives itemised from a third party and has to be matched line by line against a contract.
A retailer sells goods at a marked price. A utility bills metered consumption against a published tariff. In all three cases the commercial logic runs in one direction, the seller sets the terms, and the seller can read its own price list to know what a customer owes.
Payments businesses do none of that. The price of a single transaction is assembled from inputs the business does not own, cannot change, and often does not see until after the fact.
Difference one: you do not set the cost side
The cost of moving money is set by parties who are not in your commercial relationship.
Card interchange is the clearest case. Visa publishes its US interchange schedule as a standalone document. The current edition runs to 28 pages and carries the effective date 18 April 2026. Inside it are 234 separate rate lines. A sample of five: CPS/Supermarket, Debit $0.30. CPS/Retail, Debit 0.80% + $0.15. CPS/Small Ticket, Debit 1.55% + $0.041. CPS/Restaurant, Debit 1.19% + $0.10. CPS/Retail Key Entry, Debit 1.65% + $0.15.
Read those five rows again. They are five different prices for what a layperson would call the same thing, a debit card payment, separated by the merchant category and how the card details reached the terminal. A payments business does not negotiate them. It inherits them.
And the schedule is reissued, not fixed. The document carries an effective date because a later one will replace it. Every reissue is a change to your cost base that arrives on someone else's calendar, and the correct rate for a transaction depends on which schedule was in force the day the transaction happened.
No ordinary business prices this way. A software company does not wake up to a 28-page revision of what its own product costs to deliver.
Difference two: the same transaction does not have one price
Two identical transactions can cost different amounts, for reasons that have nothing to do with either party.
Under US Regulation II, a covered debit card issuer "may not receive, for any electronic debit transaction, an interchange fee that exceeds $0.21 plus 0.05 percent multiplied by the value of the transaction, plus a $0.01 fraud-prevention adjustment, if eligible." Institutions with total worldwide banking and nonbanking assets "of less than $10 billion as of December 31 of the previous year" are exempt from that standard.
Follow what that means operationally. Same amount, same merchant, same day, same card scheme. If the card was issued by a bank above the threshold, the capped formula applies. If it was issued by a smaller bank, it does not. The cost difference is decided by the balance sheet of an institution that is not party to the transaction and whose identity the merchant never sees at the point of sale.
The Federal Reserve's own figures show the capped side settling well below the uncapped market: across covered transactions in 2024 the average interchange fee was $0.23, which is 0.47% of the average transaction value of $48.95. Split those same figures by issuer rather than averaging them and the spread is far wider again, which is why an effective rate is not evidence.
Cross a border and the arithmetic changes again. In the EU, Regulation (EU) 2015/751 has capped interchange since 2015 at 0.2% of transaction value for consumer debit cards and 0.3% for consumer credit cards, with member states permitted to set lower credit caps and, for debit, to allow a per-transaction fee of no more than 5 eurocents alongside the percentage cap.
So a business operating in both markets is not running one pricing model with a currency conversion on top. It is running several, each with its own caps, exemptions and effective dates, and it has to know which one governed each transaction to know what that transaction should have cost. Cross-border volume does not add a column to the spreadsheet. It multiplies the number of pricing regimes the business has to be right about, which is where cross-border billing starts generating audit risk.
Difference three: two contracts govern every transaction
Here is the structural fact underneath the other two.
For a payments business, a single transaction is priced twice. Once by the provider agreement that determines what the business is charged for moving the money. Once by the client agreement that determines what the business charges its own customer for the same event. Both are contracts. Both carry conditional logic. Both get renegotiated on their own timelines.
Nothing connects them automatically. The provider contract lives in a PDF in a legal folder. The client contract lives in a different PDF in a different folder. The transaction lives in a production system that knows neither. The margin on that transaction, the number the business actually runs on, only exists once someone correctly applies both contracts to the same event and subtracts.
Ordinary businesses have one of these. A software company has a customer contract and a cost of goods sold that is not contractual per unit. A retailer has a purchase price and a sale price, both fixed in advance, both known before the sale. The payments business has two conditional pricing structures resolving against a single event, and it cannot see whether it made money on that event until both resolve correctly.
That is the reason payables and billing need the same source of truth. They are two readings of one transaction, and treating them as separate finance workstreams guarantees the two readings never reconcile.
Banks have the same problem, and they admitted it forty years ago
If the argument still sounds like special pleading, look at what banking itself built.
Banks bill corporate clients through an account analysis statement, which the Association for Financial Professionals defines as "a comprehensive financial document that banks, typically in the United States, provide to corporate account holders, often monthly," listing "the fees for banking services provided to the corporate client and any offsetting earnings credits for deposited funds."
That statement was complex enough, early enough, that the industry standardised it. AFP Service Codes are "six-character, alphanumeric codes" established in 1986 as "the standard for identifying balances and charges that appear on account analysis statements." They exist because banks could not otherwise agree on what to call the things they charge for. The codes were created for use in EDI 822, the ANSI X12 Customer Account Analysis transaction set, which carries service charges, balances, transaction volumes, compensating balance requirements and earnings credit detail from a bank to its corporate customer.
Sit with what that implies. Banking is an industry that had to invent a six-character coding standard, four decades ago, and an electronic data interchange format to carry it, purely to describe what it charges its own customers. Every other industry sends an invoice.
Forty years on, the standard has not made the problem go away. Redbridge, a treasury advisory firm that sells bank fee analysis software and therefore has an interest in the finding, reports that bank-assigned AFP code mappings are "mapped at only a 40% accuracy rate", with eight banks accredited as exceptions, and that "many banks are still using the 2004 or 2007 versions of the AFP codes." An AFP taskforce review in 2020 covered more than 2,000 active service codes.
Take that at whatever discount an interested source deserves. The structural point survives it: the industry that bills the most complex fee schedules in the economy built a standard for the job in 1986, and adoption of that standard is still contested in 2026.
What this does to the four places billing breaks
Bluefyn has already set out where fintech client billing fails in practice: tier logic, minimum fees, period-end true-ups and contract versioning. That analysis is here, and this piece does not repeat it.
What the structure above explains is why those four are so persistent. They are not sloppiness. Tier logic is conditional pricing that has to be evaluated per client per period. Minimums and true-ups only exist after a period closes, so no transaction ever triggers them. Contract versioning is hard because the correct terms depend on a date, and there are two contracts to version, not one, plus a card schedule underneath both that versions independently of either.
Fix the finance team's diligence and the four failure points remain, because the difficulty is in the structure, not the effort.
Why general billing software does not close the gap
There is a large, mature category of subscription and usage billing platforms. They handle recurring plans, metered consumption, proration and invoice generation, and they handle them well.
They solve a different problem. A subscription billing platform rates usage against a plan the business itself defines. It does not reconstruct a provider's contracted pricing, it does not know which interchange schedule was in force on a given date, and it has no concept of a second contract sitting underneath the first and determining whether the invoice it just produced was profitable.
That is not a criticism of those products. It is a category boundary. Asking a subscription billing engine to verify provider economics is asking it to do a job it was never built for, and the gap shows up as the thing every payments finance team recognises: an invoice that is arithmetically correct and commercially unverifiable.
What actually follows
If billing is hard for structural reasons, the answer is structural.
Every billable event, on both sides, gets rated against the specific version of the specific contract that governed it when it occurred. The provider side is reconstructed from the provider agreement and compared against what was actually charged. The client side is rated from the client agreement and produced as an invoice where every line traces back to the event behind it. Both sides resolve to the same comparison, expected versus actual, off the same underlying transaction data.
Done that way, the margin on a transaction stops being an estimate assembled at period end and becomes a calculation with a source. That is what fintech billing infrastructure has to mean if the term is going to be worth anything, and it is the logic behind running both sides of payment economics in one system.
Bluefyn never moves, holds, or custodies funds. It analyses transaction and provider data, reconstructs contract pricing, and checks fees transaction by transaction.
The bottom line
Billing is harder for fintechs and banks because the price of a transaction is assembled by parties outside the transaction, varies by regulator and issuer for reasons neither side controls, and is governed by two conditional contracts at once rather than one price list. Banking recognised the problem in 1986 and built a standard for it that is still only partly adopted. The familiar failures, wrong tiers, missed minimums, forgotten true-ups and stale contract versions, are what that structure produces when it meets a manual process.
The work is not to try harder. It is to rate every billable event against the contract version that governed it, and to make every line defensible.
Frequently asked questions
Is fintech billing really different from SaaS billing, or is that just complexity?
It is different in kind. A SaaS business defines its own prices and bills against them. A payments business bills against two contracts it did not write alone, over a cost base set by card networks and regulators, and cannot know its margin on a transaction until both contracts are correctly applied to it. Complexity is a matter of degree. Two governing contracts per event is a matter of structure.
Who actually sets the cost of a card transaction?
Not the payments business, and not its client. Interchange is set by the card network's published schedule, the scheme applies its own fees, and the acquiring relationship adds a markup on top. Regulators cap parts of it in some markets and not others. The business inherits the result and has to verify that what it was billed matches what those rules and its contract say it should have been billed.
Why does the same transaction cost different amounts?
Because the cost depends on facts outside the transaction. Under US Regulation II the capped interchange formula applies only to issuers with $10 billion or more in total assets, so an identical payment costs differently depending on which bank issued the card. Across borders the caps themselves differ, with the EU limiting consumer debit interchange to 0.2% and consumer credit to 0.3% of transaction value.
Do banks have this problem too, or only fintechs?
Both, and banks have had it longer. Banks bill corporate clients through account analysis statements complex enough that the industry created AFP Service Codes in 1986 and the EDI 822 standard to carry them. Four decades later, adoption of those codes is still inconsistent across institutions.
Can subscription billing software handle fintech billing?
Not the part that matters. Subscription and usage billing platforms rate consumption against plans the business defines, which is a real job done well. They do not reconstruct a provider's contracted pricing, do not track which fee schedule was in force on a given date, and carry no second contract governing the cost side of the same event.
What is the first thing to fix?
Establish which contract version governed each billable event, on both sides. Almost every downstream error, wrong tier, missed minimum, unapplied true-up, stale rate, is a version or a condition applied incorrectly. Once every event is anchored to the right version of the right contract, the rest is arithmetic that can be checked and evidenced.
