Payment reconciliation for software platforms: writing settlement back to invoices

Every finance team at every one of your customers has the same Monday morning. A credit of £4,318.62 has arrived from the payment provider. It does not match any invoice. It does not match any sum of invoices they can find in ten minutes. It is somebody's Thursday takings less some fee, possibly less a refund, possibly across two days, and the only way to find out is to download a report from the provider's dashboard, open it next to the sales ledger, and match lines by hand.

That is reconciliation as most small businesses experience it, and it is the reason the bookkeeper is the person who most resists a change of provider. If your product can close the gap, so that each payment lands against the invoice it paid with its fee shown, the bookkeeper becomes the person who most wants your payments. It is the plainest example of a payment product that keeps customers.

Matching starts with an identifier that leaves your product with the payment and comes back with the settlement. If the invoice number, or an identifier your product can map to it, is set on the payment at the moment it is created, every later record of that payment carries it: the authorisation, the capture, the settlement line, the refund if there is one. Matching is then a lookup, not a search.

The constraint is the rail. A card payment can carry a reference of useful length through the provider's records. A UK Direct Debit collection is different: the Bacs scheme allows an 18-character payment reference and a 10-character mandate reference, and that limit is why reconciling bank transfers in the UK is harder than it should be. The Euro Banking Association's working group on remittance data named the 18-character Bacs field as a cause of remittance data being separated from the payment and the two having to be matched afterwards. The answer for a platform is not to squeeze the invoice number into 18 characters but to keep the full identifier on the provider's record and use the short reference only as what the payer sees on their statement.

What your developer builds here: the call that creates the payment sets your identifier; the record your product stores keeps the provider's identifier; and the event handler that receives the settlement writes the match. That is the whole of the integration work for this piece, and a payments engineer can tell your developer exactly which field carries what.

Payments do not arrive in a bank account one at a time. They arrive as a settlement: a batch of captured payments, less refunds and chargebacks, less fees, paid as one credit. The reconciliation question at the batch level is "which payments made up this credit?", and it is answered only if the provider's settlement record carries a key that ties each payment line to the bank transfer it was part of.

On Synapto, every line of the settlement report carries the reference of the payout it was part of, so grouping the lines by that reference reproduces each bank credit to the penny. The check we suggest to a platform's finance team, weekly or monthly, is at the level of individual payments: the payments in the report against the invoices in your product, not just the credit against the bank statement.

For your product, the batch key is what lets a bookkeeper click a bank credit and see the list of invoices it closed. Without it, your product can say an invoice was paid but not when the money arrived or in which credit, and the bookkeeper is back to matching by hand.

A netted settlement is one where the fee has been taken off the total and nothing says how much, or against which payment. It is the single biggest reason reconciliation fails: a £100 invoice settles as £98.71 and the ledger has nothing to post the £1.29 to.

Itemised means each payment line shows the gross amount, the fee components and the net, so your product can post the gross against the invoice and the fee to a fee account in the same movement. Under interchange++ pricing, the components are interchange (paid to the card issuer), the scheme fee (paid to Visa or Mastercard) and the provider's own margin.

Synapto goes a step further for software platforms. Each of your customers is settled in full: the bank credit is the value of the payments in the batch, less any refunds and chargebacks, with no fee taken off. The fees arrive once a month on one statement, itemised per payment as interchange, scheme fee and our margin, and the lines add up to the statement total. So your product posts the gross against each invoice as it settles, and the fees post from one statement at month end. A few fees are charged per period rather than per payment; your developer should know which before designing the write-back. Marketplaces work differently: the payment is split at capture, and each seller's report shows the platform fee against every payment.

The test is simple. Take any bank credit, and from your product alone, without opening the provider's dashboard, list the invoices it closed, the fee on each, and the refunds and chargebacks that reduced it. If the list adds up to the credit, reconciliation is built. If it does not, it is not.

Before. A customer of your platform, a small business, sends invoices from your product and takes payment through a provider the customer chose years ago. Each week their bookkeeper downloads the provider's settlement file: a spreadsheet of payments by date, each showing a net amount after an unlabelled fee, with the payer's name and a provider-generated reference. She opens the sales ledger beside it. Four payments match by amount. Two are a single customer who paid two invoices in one go. One is a part payment. One is a refund from last week that has reduced Tuesday's batch. Each guess takes a few minutes; the last two take twenty. The fees are posted as one lump at month end from the provider's invoice, which does not agree with the sum of the deductions by a few pence because of rounding, and nobody chases the pence. The bank credit is reconciled by Monday, usually.

After. The same customer takes payment through your product. Each payment was created with the invoice identifier on it. When the settlement event arrives, your product marks each invoice paid with the date and the batch it was part of, posts the gross to sales and the itemised fee to a fee account, and attaches the refund to the invoice it reversed. On Monday the bookkeeper opens the bank feed, sees the credit, and sees in your product the list of invoices and fees that make it up, totalling the credit to the penny. The part payment shows as a part payment. The two-invoice payment shows against both invoices. The provider's dashboard is not opened. The time saved is real, but the thing that keeps the customer is that reconciliation is no longer a job.

Reconciliation is a payment product in the sense this site uses the phrase: something built on top of the payment that makes the customer's business run better when the payment goes through your product. It is also the feature that most often gets cut from a first launch and most often turns out to be the reason customers do not move. A customer's bookkeeper who has learned to live with the weekly spreadsheet has no reason to change; a bookkeeper who has seen the Monday version has every reason.

What Synapto brings is the settlement data in a shape that can be written back (your reference carried through, the payout reference on every line, fees itemised), and the design of the write-back with you. What your developer builds is the mapping into your own ledger, because only your developer knows how your product models an invoice, a credit and a part payment. No timeline is given for that build, because it is theirs.