What the Bank Connection Can See: Statements, Windows and What Disappears on Disconnect
There is a difference between signing in to online banking and letting a CRM read a bank statement, and the difference is not cosmetic. When a Firmspace account is connected to a bank, the firm creates a token in the bank's API cabinet and pastes it into the CRM. That token is not the password of the banking application and it does not open the personal cabinet. It is a read key for statements, and it can be withdrawn from the bank's side at any time.
Firmspace describes each bank integration with a small capability record, and the record for the bank connection is honest: statements yes, balance no, webhooks no, payment initiation no. In plain language: the CRM can download the movements of the account, it cannot move money, it cannot show a live balance, and the bank does not push anything into the CRM by itself. The statement arrives when someone asks for it.
That request is an explicit action: updating all linked accounts goes through one route, which walks the firm's accounts one by one and reports for each whether it imported rows or failed with a message; one broken connection does not stop the others. The daily background pass is a different list — it handles delayed automation, overdue invoices, recurring invoices, payment reminders and mailboxes — and bank statements are deliberately not in it, because a surprise import at night is harder to explain than a click. The sync also respects a closed accounting period: rows dated inside a month that has been locked are refused, and the answer says so.
Before a token is stored, it is used once to read the client and the list of accounts. A wrong token comes back as a plain message asking to copy it from the API cabinet again; a token taken from the mobile application is refused with its own explanation; a rate limit answers that the bank asks to wait an hour. Only then is the token encrypted and written to the database, and it is never returned to the browser: the account list shows the name, the currency, the balance where the bank provides it, the last four digits of the IBAN and the time of the last sync.
Linking is idempotent in the ordinary sense: connecting the same bank account again updates the existing record instead of creating a second one, and the account name is unique inside the firm, so a duplicate name receives the tail of the number. The name and the currency are taken from the bank's answer, not from the form, which means the CRM does not quietly invent a euro account. An account that is not present in this banking cabinet is refused.
A statement row is small and specific. The bank sends the amount in minor units and the time in Unix seconds; Firmspace converts the amount to major units with a coin-level rounding, keeps the sign so that an incoming payment stays positive and an outgoing one negative, and dates the row by the moment of the operation. The counterparty is stored as the bank writes it, together with the payment purpose, and the bank's own row identifier is stored as the external identifier. Currencies arrive as numeric ISO codes and are mapped to their three-letter form.
The bank does not give a year of history in one answer. A statement request covers at most thirty-one days and a limited number of rows, and Firmspace cuts a longer period into windows, stitches the answers and removes repeated identifiers. A single sync is capped at ten windows — roughly ten months — so that an accidental request from a distant past cannot burn through the bank's rate limit. The window itself starts at the previous sync with a day of overlap, and on the first connection it does not reach deeper than a month: a CRM does not need the account's whole biography to reconcile this quarter.
Repeating a sync does not duplicate the ledger. Every row is written with an external identifier that carries the bank's prefix, the known identifiers for the account are loaded before the insert, and rows that are already present are counted as skipped. This is why pressing update twice, or pressing it after a timeout that looked like an error, does not double the turnover. It also sets the limit of the promise: two different identifiers are treated as two different movements, even if a person suspects they are the same transfer, and only a human can decide otherwise.
New rows are not left as raw noise. The importer looks for an open invoice or a matching expense and marks a link only when the evidence is strong — the document number appears in the purpose, or the amount and the date are aligned. A weak coincidence, such as the same amount without any other support, remains a suggestion that a person confirms. Firm rules of the counterparty-contains-this kind are applied immediately to new rows and count their hits. What the importer does not do is invent an invoice or a client to make the row look tidy.
Consent is not a paragraph in a policy, it is a record. Linking an account writes a consent entry of the bank connection kind, tied to the specific account, with the purpose and the person who connected it. Disconnecting is equally concrete: the consent is marked revoked with the date and the author, the stored secret is wiped, the last sync time is cleared, and synchronization stops immediately. Rows that were already imported stay where they are, because they are part of the firm's accounting history; nothing new arrives for that account.
The honest limits are worth stating next to the feature. The connection cannot know what a client intended, it cannot prove that two bank rows are one transfer, it cannot show a balance that the bank does not expose, and it cannot write into a closed month. If the stored secret is empty or cannot be decrypted — a rotated key, a restored database — it is treated as not saved at all, and the account asks to be linked again rather than failing silently.
The practical conclusion is small. Sync before closing a month, not after it; treat the suggested matches as suggestions until a person or a rule confirms them; keep the consent register next to the account list, because that is what an auditor or a client will ask about; and remember what the connection actually is — a read key for statements, not a remote control for the bank account.