A payment is not money in the bank

A customer lands on your checkout page and pays. The funds are captured. Bram van Kessel of Actuals gave a 45-minute breakout session on what still has to happen before that money is really yours.

He started with the one thing every company shares. However your business is set up, it ends with an incoming bank transfer. When Actuals talks to new clients, it always finds that they record the cash. Everything before that moment is more open to debate: what you record, and when.

Sven Liefting opened the session with Bram and asked the room for one thing: think about your own company. Everyone had a form with statements. If you already do what a statement says, you tick the box. If not, or if you are unsure how, you write it down. This article follows the same route, so you can keep score as you read.

Start by mapping your own flow

Bram used 4 steps to map an order-to-cash process. The first is to list the events. Some companies register orders. If you sell physical goods, you may need fulfilment, a step some SaaS companies have less of. Then invoicing: do you create invoices at all, and if so, when?

At high volume, a payment service provider (PSP) usually sits in the middle to collect the payments. It rarely pays them out one by one. It settles them in batches, and at the end you see a bank transfer.

The second step is to link each event to something you can record in your ERP. You might book revenue when the order is created, at fulfilment, or when you issue the invoice. With the invoice you probably also record a VAT liability and open a receivable.

The third step is to find where each piece of data starts, and take it from as close to that source as you can. Once another system has translated it, something may be missing. For payments and settlements, the source is your payment service provider. For bank transactions, it is the bank.

The fourth step is to decide which reconciliations you need. Bram's advice for the whole exercise: watch every point where data passes from one application to the next.

Payment and settlement are 2 separate moments

Bram split the provider part of the flow into 2 phases. The first is the payment itself: the customer goes through checkout and the funds are captured.

That raises the hard question: how and when do you record your payments? Bram walked through the journal entries for the simplest case, a company that books revenue as soon as it issues the invoice.

When the customer pays, you credit accounts receivable and book a balance at your payment service provider. From then on, the customer no longer owes you the money. Your provider does. For this to work, you need to get that payment data out of your provider.

Fees need care here. A provider usually charges per transaction, and probably per settlement as well. To credit accounts receivable correctly, you need to split out the fee on each transaction. Otherwise you book an amount that is already net of fees, and it will not match the invoice.

At settlement, you debit a transitory account and credit the provider balance. That way you can see what is still sitting at your provider, apart from what it has already decided to pay out. When the cash lands in the bank, you can link it straight to that settlement, which makes reconciling easy.

Each of these entries needs its own reconciliation. On accounts receivable, you want to know which invoices are paid and which are still open. The invoices live in your back end and the payments at the provider. Both systems need enough shared data to match a payment to the right invoices, for example when a customer pays several at once. Matching the bank is a lot easier if the provider settles once a day per currency.

Record events, then work out the status

The first statement on the form was about recognising revenue on an accrual basis. Bram sees many companies that struggle with order-to-cash fall back on whatever the provider settled. They cannot trace that amount back to invoices or orders, so cash is the only certainty they have.

The next statements were about linking. Can you link your revenue entries to your invoices, even when the timing differs? You cannot record more revenue than you invoice, or the other way round. Some companies book revenue from the order system, then something changes before the invoice goes out, and the figure is no longer right. And if someone cancels an order you had not yet invoiced, do you see it?

Bram made a case for proper invoices. Some e-commerce systems, Shopify for example, do not require them. But an invoice fixes a transaction at a point in time. Any later change means a credit note, so you add a new transaction instead of editing the old one. The alternative is to record an event for every change.

VAT got its own statement. The order system often holds what you need for your VAT return, such as where the customer is and whether they buy goods or services. If your postings come from another source, matching the VAT return to your general ledger gets hard.

Then came a statement on payment status. When companies start building, many store a payment status: paid, unpaid, maybe partially paid.

Having a payment status and only recording that status comes with an issue. Because payment status can change.

You can never be fully sure you recorded the previous payment. Maybe you missed some. Record each payment and each refund as its own event, and derive the status from those. Then you can check that nothing is missing.

Inside the payment black box

On one side are the items your customers pay for. On the other, money arrives in your bank account. A lot can happen in between. Bram calls this the PSP black box, and he asked the room to guess what is inside. The room answered: settlement details, fees, chargebacks, currency conversion.

His own list: gross payments in, refunds and disputes out, and all kinds of fees. Depending on the type, a fee comes off per transaction or per day. Then there is currency conversion. To match your invoices you ideally want the payment currency. To match your bank statement you need the settlement currency.

There are adjustments as well. Above a certain volume, a provider may see a risk, because customers can raise disputes, and start adding to your reserve. Where it sees risk, it may also hold part of your balance for longer because of possible chargebacks. Some providers also invoice you for their services, either by deducting the amount from the settlement or separately.

The most important thing is that each of these aspects comes with a time issue.

A calculation you make today may not add up yet. A hold might last 30 days. One payment method might settle 1 day later than another.

Someone in the audience knew this from experience. Some fees only show up after 4 or 5 days, while most people want yesterday's revenue in the books today. If that takes 4 or 5 days, you are playing catch-up again.

Pick the right report from your provider

Bram usually sees 3 types of report. For accounting, the best is a balance report. Some providers give you something like a bank statement, listing every event of the day in and out of your provider balance. With more than one currency you may have several balances, just as you would hold a bank account per currency.

You can cut that report by date and it covers every inflow and outflow, since each fee hits your balance sooner or later. The catch: not all providers offer it.

The second type, and a common one, is the settlement details report. It specifies everything that was settled, so you can allocate every bank receipt. But you only get it once the money has settled. With a long settlement delay, your receivables stay open until then. And if the report does not fully explain the currency conversion, you only see amounts in the settlement currency. That makes receivables hard to match.

The third type is the payment report, often daily, which lists the payments. That makes them easy to reconcile, but it does not tell you which fees come off later or when the money will reach you.

So check what your provider can give you. Actuals always asks its partner providers for this kind of detailed report. Providers do not always want to show every fee, because currency conversion is one of the ways they make money. Another route is to combine the payment and settlement reports. You then reconcile your invoices when the payments come in, and still match the bank once they settle.

After the session, Bram said he hopes regulation will one day require providers to offer certain standard reports.

Which truth are you talking about?

Bram's last slide came from his conversations with customers. People tell him they have an open-item report. But which one?

First there is the merchant truth, often kept in an e-commerce platform: an order is paid or unpaid. That need not match what your payment service provider shows. The merchant truth usually relies on webhooks, which arrive correctly almost every time, "but sometimes they don't".

The moment you miss one of these events, you already have an incorrect statement

So basing your accounting entries on the merchant truth alone is really risky, because you often have no report that you reconcile daily or monthly against the provider truth. The third version is the cash truth: what settled and shows up in your bank.

Bram's advice: agree as a team which truth you mean, on the operational side and the accounting side. Then you can have a proper discussion, find the mismatches and correct them.

Where does the transaction detail live?

The last statements on the form were about your ledger. Do you reconcile your transitory and clearing accounts? If you aggregate entries in your ERP, can you trace them back to single transactions, and do you reconcile at that level? Do you process data on a fixed schedule? And the one Bram called perhaps the most important: if your clearing accounts do not match, do you have a repeatable way to fix it?

After the session, someone in the audience asked where all this transaction detail lives: in the ERP, or on Actuals' own platform? Bram's answer: at very high volumes, moving every transaction into the ERP creates a huge number of entries. And ERP matching is built to pair an invoice with a payment. Actuals takes that detail out of the ERP and does the matching per transaction.

Because a transaction is not the same as a journal entry.

Bram agreed. Earlier in the conversation he had put it this way: you do want some aggregation, but once you aggregate, you have made a translation step, and that is where it goes wrong.

What to do on Monday

1. List the events in your own order-to-cash flow, from order to bank transfer, and decide what you want to record at each one.
2. Take your data as close to its source as you can: payments and settlements from your provider, cash from your bank.
3. Split out provider fees per transaction, so you credit accounts receivable with the right amount.
4. Record each payment and refund as an event, and derive the status from those events.
5. Ask your provider which reports it offers. Use the balance report for accounting if you can get it, or combine the payment and settlement reports.
6. Agree with your team which truth you mean: the shop, the provider or the bank. Reconcile the shop view against the provider regularly.
7. Reconcile your transitory and clearing accounts on a fixed schedule, with a repeatable way to correct mismatches.