Invoices that just get paid
Every month the invoices arrive. Your banking partner charges per account and per payment. The card processor charges per card issued, per transaction and a platform fee. The identity verification provider charges per check, with different prices for document checks and database checks. There may be a monthly minimum on some and a volume tier on others.
Finance get the invoices as PDFs, look at the totals, compare roughly with last month and pay. Nobody has a list of what you actually used, because the usage lives in each provider's dashboard and your own database. When someone does try to check, it takes days and the numbers do not quite line up.
Why checking is hard
Provider costs are some of the largest bills a young fintech has, and some of the least examined.
- Contracts have tiers, minimums and different prices per event type.
- Invoices group usage differently from how your systems record it.
- Retries, test calls and failed attempts may or may not be billable depending on the contract.
- Nobody owns the question of whether the invoice is right.
- Pricing changes and new contracts are stored in email.
What unchecked invoices mean
You may pay for checks run twice due to a bug, for cards that were never activated, or at a tier you have moved past. You may miss that sandbox usage was billed. Or you may be underbilled now and surprised by a catch-up later. Either way, unit economics built on the invoice total are less accurate than they look, and a provider conversation about a disputed line needs evidence you do not have.
Whether a line is billable under your contract is for you and the provider to agree. The build gives you the facts to discuss it.
A usage record and an invoice check
What we build is a finance-side record of billable usage and a comparison with each invoice.
- Billable events are captured from your own systems: checks requested, accounts opened, cards issued, payments sent, with the provider and the event type.
- Each provider's contracted rates, tiers and minimums are stored as data, with effective dates, by someone in finance.
- At month end, expected charges are calculated per provider and per invoice line.
- The invoice is entered or read from the PDF, and each line is compared with the expected figure.
- Differences are listed with the underlying events, such as the duplicate checks on a particular day.
- Finance mark each difference as accepted, queried or credited, and the result is kept for the next month.
| Provider type | Typical billable events | Common differences |
|---|---|---|
| Identity and verification | Document checks, database checks, re-runs | Duplicate checks from retries |
| Banking partner | Accounts, payments, statements | Closed accounts still counted |
| Card processor | Cards issued, transactions, platform fee | Inactive cards billed, tier not applied |
| Messaging, such as Twilio | Messages and verification codes | Resends and failed deliveries |
The same usage record often shows engineering problems, such as a retry loop that runs checks twice. Those are worth fixing in their own right.
Paying invoices with evidence
At month end, finance sees each invoice next to what you expected to pay. Most lines agree. The few that do not come with the underlying events, which makes a query to the provider short and specific. Cost per customer in your reporting uses real usage, not an estimate.
Does this describe your provider costs?
- Provider invoices are approved on the total.
- Nobody has a usage record independent of the providers.
- Contract rates and tiers live in email and PDFs.
- You suspect some checks or messages are sent twice.
- Cost per customer is estimated, not measured.