Bank feeds
Through Plaid or direct connections where available, across operating, payroll, savings, and foreign currency accounts, with balances and transactions refreshed daily.
Services · integration
A bank feed tells you money arrived. It does not tell you which invoices it settled, what was netted out of it, or why the deposit is $84 short. That gap is where reconciliation time goes, and it is almost entirely mechanical.
Tell us your banks, cards, and processors. We will scope the reconciliation and price it.
The situation
Feeds are the easy part. The work is in decomposing settlement and matching it to what it paid for.
Through Plaid or direct connections where available, across operating, payroll, savings, and foreign currency accounts, with balances and transactions refreshed daily.
Ramp, Brex, Amex, Expensify, and Navan, with the receipt, the merchant, the cardholder, and the coding brought together rather than arriving as three separate feeds.
Stripe, Adyen, Shopify Payments, and PayPal broken into charges, refunds, disputes, fees, adjustments, and reserves — because a net payout cannot be reconciled to invoices.
Deposits matched to receivables including partial payments, batched payments covering many invoices, and short payments where a deduction needs investigating.
Foreign accounts with the rate applied at the correct date, realised and unrealised gain calculated, and the revaluation posted rather than adjusted at year end.
What did not match, with the candidates and why each was rejected — which is far more useful than a match rate on its own.
A processor deposits a single figure that represents dozens of charges, minus refunds, minus fees, minus a dispute, plus a rolling reserve release. Booked as one line against revenue, it is unreconcilable by construction — and it is how most companies book it, because the alternative is manual.
The specific accounting error that follows is fees netted against revenue rather than posted as expense, which understates both revenue and cost and distorts gross margin. It is the single most common processor mistake we find, and investors notice it during diligence.
Exact-amount single-invoice matches are trivial. What takes the time is a customer paying eleven invoices with one wire, short by $340 because of a disputed line, referencing a purchase order number that does not appear in your system.
We match on amount, reference, customer, date proximity, and combination search across open invoices, and we publish where it fails. Around 93% of bank lines match automatically in a typical account after a few weeks. The remaining 7% is judgement and stays with a person.
Card spend fails on coding rather than matching. The transaction is unambiguous; what is missing is which project, which department, and whether a receipt exists. Bringing the receipt, the cardholder, and the merchant history together is what makes coding automatable — and it is why we connect the spend platform rather than just the card feed.
Applying a month-end rate to everything is simpler and wrong. Rates at transaction date, realised gain on settlement, unrealised on revaluation, posted to their own accounts — that is more setup and it is the difference between an FX line you can explain and one that absorbs errors.
Where to start
Every account, card programme, and processor, with volume and current reconciliation effort per path. Some are usually forgotten until this exercise.
Feeds established, twelve to twenty-four months of history pulled, settlement decomposed retrospectively so prior periods become reconcilable too.
Matching rules configured against your actual payment behaviour, with the exception queue reviewed weekly for the first month.
Match rate per account reported openly, including the accounts where it is poor and why. A rate you cannot see is a rate we could quietly overstate.
Questions
Send a list of your accounts, cards, and processors. We will scope it and estimate the match rate.