Case
The bank posts itself
Every morning the statement becomes documents in the accounting system.
≈ the owner's estimate from his own experience
Before
In most companies the statement is posted by hand several times a day. In ours the accountant did it once every two or three weeks: for every payment, find the counterparty, work out what it is, create a document, match it to an invoice. Between two postings, balances with clients were inexact, and "have they paid yet?" was settled by calling the accountant.
What I built
- Every morning at seven the statement is pulled from the bank through its API.
- Each payment is classified into one of six kinds: a client payment, a payment to a supplier, taxes, bank fees, a refund, other.
- The payment becomes a document in the accounting system and is matched to invoices by FIFO: the oldest unpaid one first.
- Whatever is not recognised — a new counterparty, an odd payment reference — is parked for review, and the accountant sees only that list.
After
The statement posts itself every day. The accountant spends time on a few unrecognised payments a week instead of on the whole statement.
What it gave
Balances with clients are accurate today. A sales manager sees the payment the same morning and ships without asking the accountant. One more routine that no longer exists.
For your company
In my company the statement is collected daily at seven, because that suits the accountant. It can be hourly, several times a day, or the moment a payment arrives — the schedule is yours. So is the bank: some companies have one, others three plus card acquiring and cash on delivery. The kinds of payment and the matching rules are described around your books: mine are six kinds and FIFO, yours may be different.
Stack: Python, bank API, payment classification into 6 kinds, FIFO matching to invoices
Related service: Analytics and control