Bank Rules and Batches: How Firmspace CRM Gives Every Transaction a Category — and Asks Before Changing Anything
A bank statement is a wall of text that answers a simple question badly. Money arrived, money left, and none of it says which line of the books it belongs to. In Firmspace CRM the statement is not retyped by hand: the rows are pulled straight from the bank, and everything after that is about one thing — giving a row its category without a person reading every line.
Two banks are connected by API in the accounting section: monobank and PrivatBank, both for Ukrainian firms. The firm takes a token in its own bank cabinet and links the account; the CRM talks to the bank itself, pulls the statement by itself, and refreshes all linked accounts with one action. The tokens are stored encrypted and are not returned to the browser. The account statement is requested in windows, not for years at once: the bank's API cannot return more than thirty-one days and five hundred rows per request, so the CRM cuts a long period into windows and glues the pieces together. The first sync takes the last month; every later one continues from the previous sync minus a day of overlap, so a transaction is not lost if it was posted late.
What happens to a row the moment it arrives is worth reading twice. A new row becomes a movement in the journal. A duplicate is not created: repeated import of the same statement is recognised by the external identifier of the row. And then the CRM tries to guess the pair for the row — which customer invoice it pays, or which expense it settles. Income is matched against customer invoices, spending against recorded expenses.
The guess has three levels of confidence, and the difference between them is the whole point. If the invoice number is found in the payment reference, the match is strong. If the amount coincides and the dates are within fourteen days of each other, the match is also treated as reliable. If only the amount coincides, it is a weak guess: the CRM does not decide — it leaves the row as a suggestion for a human to check. That is the honest line between 'the machine knows' and 'the machine thinks'.
The second mechanism is the firm's own rules. A rule is a plain visible sentence: if the counterparty or the payment reference contains this string, the category is that one. It is not machine learning and not a black box — it is a rule you can read, show to an accountant and delete. Rules are checked in order, the first suitable one wins, the case of letters does not matter, and the searched string must be at least three characters long. A firm may keep up to two hundred rules, and they are set by the owner, an administrator or the practice specialist.
Rules work in two directions at once. New statement rows are labelled on the way in, during import, so a familiar payment gets its category immediately. And rules can be applied to what is already lying in the journal without a category: the CRM walks through unlabelled movements, labels those that match, and the rule itself counts how many rows it caught. The rule's hit counter is not decoration: it shows which rule earns its keep and which one was written once and never fired.
Closed periods are respected. If an accounting period is closed, a rule does not rewrite it — such a row is simply skipped. And if mass relabelling feels too abrupt, there is a softer path. The assistant can prepare a batch: it takes the firm's rules, finds unlabelled movements they match, and shows exactly what it is going to change — without writing anything yet. The batch starts as a proposal, not as a fact.
Then a person decides. The proposal can be reviewed, applied or rolled back. And there is one more safeguard hidden inside: before a batch is applied it checks that the field is still what it was when the batch was prepared. If someone corrected a row by hand in the meantime, that row is skipped — a person's edit is never overwritten by a prepared list. Rolling back works by the same logic: the batch restores only those movements that still carry the value it put there, and quietly leaves the hand-corrected ones alone. Movements in a closed period are skipped during rollback too.
Why does this matter, when an AI can label almost anything? Because bookkeeping is not a quiz. A category that cannot be explained is a category that cannot be defended to an accountant or a tax inspector. Here the explanation is a line in the rules list: this phrase, this category, this many rows. Anyone can check it, and anyone can turn it off. The AI's role is narrower and more useful — it does the bulk work and prepares the batch, while the decision stays with the person.
The practical result is modest and pleasant. One good set of rules removes the monotonous part of working with a statement: the same supplier, the same payment purpose, the same category, dozens of times a month. The rules keep doing it, the assistant keeps suggesting pairs, and the human is left with the genuinely interesting cases: an unfamiliar counterparty, an amount that does not match any invoice, a payment that arrived without any comment at all. That is a sane division of labour between a rule, an assistant and a bookkeeper.
What we cannot state here is how much time this saves in a particular firm. There is no measurement of that in the product, and inventing a percentage would be dishonest. What can be checked is the mechanics: rules are visible, batches are reviewed before applying, apply and rollback both keep a person's manual edits, and the AI quota is not spent on work that explicit rules already do — no AI is used in the rules and batches path at all.