How transactions get into your books

Almost every complaint about bookkeeping is really a complaint about data entry. The judgement calls are the interesting part of the job and they are not where the hours go; the hours go into getting transactions into the system in the first place, and then into working out which of them match which invoice.

Here is how that path works in Tiybe, and — just as usefully — where it stops.

Step one: getting the transactions in

There are two ways in, and they suit different situations.

Statement upload. Tiybe accepts bank statements as PDF or CSV. This is the universal option: it works for any bank, any account, and any period, including the historical months you are catching up on. It is also the fallback when a connection is unavailable for whatever reason.

Live bank feeds. Where a connection is available, transactions arrive on their own instead of waiting for someone to remember to export a statement. The practical gain is not the minutes saved on the export — it is that the books stop being a monthly event. A feed means the ledger is roughly current all the time, which is the difference between answering "how are we doing" today and answering it after a three-day close.

Feed availability depends on your plan; the pricing page comparison table says which plans include them.

Step two: making sense of them

A raw bank line is a date, an amount and a piece of terse text. Turning that into an accounting entry is a classification problem, and it is the one that repeats thousands of times a year.

AI transaction categorisation proposes the account for each line. AI invoice and bill extraction does the same job for documents rather than bank lines — reading a PDF invoice or a photographed bill and pulling out the fields that would otherwise be typed in by hand.

Both are metered. Each plan carries a monthly allowance for categorisation, for extraction and for agent commands, and those allowances are shown as actual numbers on the pricing page rather than as a vague "AI included". We would rather you could see the limit before you buy than discover it in week three.

Step three: reconciliation

Categorising a transaction says what it was. Reconciliation says what it belongs to — which invoice this receipt settles, which bill this payment clears.

Tiybe's AI reconciliation engine proposes those matches. Anomaly detection works the other end of the same problem: flagging the entries that do not look like the rest — the duplicate, the figure with an extra digit, the payment that does not correspond to anything.

Both are available depending on plan, and both are proposals.

Why "proposal" is the important word

It would be easy to write this article as though transactions flow in and post themselves. They do not, and a system that claimed otherwise would be one you could not sign off.

Every suggestion — the category, the extracted field, the match — is presented for a person to accept, change or reject. That is not a limitation waiting to be removed; it is the design. An automated match that is wrong and silent is worse than no match at all, because it costs more to find later than it saved when it was made.

What automation genuinely changes is the ratio. Instead of classifying every line, you review a screen of proposals and spend your attention on the handful that are actually uncertain. The judgement stays with you. The typing does not.

What this adds up to

The reason to care about the capture path is that everything downstream inherits it. Returns are assembled from the books; reports are read off the books; a close is only as quick as the backlog that has to be cleared first. Getting transactions in continuously, with the routine classifications proposed rather than typed, is what makes the rest of it ordinary.

If you want to see it against your own bank data rather than a demo file, ask for a walkthrough — or start a free trial from the pricing page.