Two weeks in spreadsheets
The month ends. Finance downloads statements from your banking partner, settlement reports from the card processor, a ledger export from engineering, fee reports from your own admin panel and invoices from each provider. They build a workbook. Interchange income comes from one report, FX margin from another, customer balances from the ledger, and none of them agree on when the month ended.
Journals are typed into Xero or NetSuite by hand. Two weeks later the accounts are closed, just in time to start on next month.
Why a fintech close is harder than it looks
A fintech's revenue and costs are made of very many small events, recorded by several systems.
- Revenue comes in many forms: interchange, fees, FX margin, interest, subscription.
- Each provider report has its own cut-off time and time zone.
- Customer balances in your ledger have to tie to money held at the provider.
- The chart of accounts in your accounting system does not match the categories in your data.
- Everything is summarised by hand once a month, so errors are found late.
How revenue should be recognised and accounted for is for your finance team and accountants to decide. The build carries out the rules they set, consistently.
The cost of a slow close
Two weeks of close is two weeks when finance is not doing analysis. Board packs and investor updates are late or based on estimates. Errors caught at month end are harder to trace than errors caught the day after. And when the business grows, the close grows with it, because the manual work scales with volume.
A close built on daily data
What we build moves most of the work to every day, automatically.
- Your ledger events and each provider's reports are loaded daily into a finance data store, with cut-offs normalised to one definition.
- Each event type is mapped to your chart of accounts using rules your finance team set and can change.
- Daily checks tie customer balances to the provider position and flag differences, using the reconciliation if you have one.
- Provider costs are matched to their invoices where available.
- At month end, summary journals are generated and posted to your accounting system through its API, such as Xero or NetSuite, as drafts for finance to review.
- A close checklist shows each check, its result and who signed it off.
| Area | Daily | Month end |
|---|---|---|
| Fee and FX income | Loaded and categorised | Summary journal drafted |
| Interchange | Loaded from processor reports | Summary journal drafted |
| Customer balances | Tied to provider position | Balance check signed off |
| Provider costs | Usage captured | Matched to invoices |
| Adjustments | Logged as they happen | Reviewed and posted |
Take FX margin as an example. A customer converts currency late on the last day of the month. Your ledger records it on that day in UK time, the provider's report puts it in the next month because it uses a different time zone, and the settlement arrives two days later. In a spreadsheet close, someone has to notice and move it. In the daily model, the cut-off rule is written once, the item lands in the right month, and the difference with the provider's report is shown as timing rather than left as a mystery.
Edge cases like this are where most close time goes, so we collect them with your finance team during the build and turn each one into a rule or a flagged item.
Month end as a review
On the first working day, draft journals are waiting in your accounting system with the underlying detail a click away. Finance review, question and post. Differences have already been found during the month. The close checklist shows what is done.
The same finance data store feeds board metrics, so the numbers in the board pack match the accounts.
Is your close like this?
- Month end takes one or two weeks.
- Journals are typed into your accounting system by hand.
- Provider reports disagree on cut-off times.
- Customer balances are tied to the provider only at month end.
- Board numbers and accounts numbers differ.