Accounting & Bank Feeds

Connecting a Feed Provider

Feeds bring transactions in from outside. Accounting packages and bank connections are sources; the ledger is where the record lives.

What ships, and in what state

Adapters are provided for the major accounting packages and bank connections. Every one of them ships disabled and without credentials, in keeping with the platform-wide rule that nothing starts talking to an external service because somebody applied an update. You enable the ones you want and supply your own credentials.

Setting one up

1. Enable the provider you need and enter its credentials. The provider row follows the same shape as the platform's other external connections, so it will look familiar if you have configured a login method or a mail relay.
2. Create a connection binding that provider to a specific entity and a specific ledger bank account. This is what tells the system whose books an incoming transaction belongs to.
3. Test, and confirm transactions land in the inbox rather than posting straight through.

One connection per account

Resist pointing several bank accounts at one connection. The connection is what resolves which ledger account a transaction hits, and sharing one across accounts means the resolution has to be inferred from the transaction, which is exactly the kind of guess that produces a misposted month.

Webhook receipts, including failures

Every webhook received is recorded — including ones that failed signature verification. That is deliberate. A rejected delivery is not simply noise: a run of them means either a misconfigured credential or somebody probing the endpoint, and neither is visible if failures are silently discarded.

Check this log when a provider insists it has sent something you cannot find.

Credentials

Feed credentials permit reading your financial data. Treat them like any other production secret: give the connection its own credentials rather than reusing a person's login, so access can be revoked when somebody leaves without breaking the feed.

The Feed Inbox

Incoming transactions do not post directly. They land in an inbox and wait, which gives you a point of control between an external system and your ledger.

Why stage at all

A feed does not know your chart of accounts. A bank line saying a card payment left the account does not know whether that was stock, a subscription or somebody's lunch. Staging is where that decision is made — automatically where a rule matches, by a person where it does not.

It is also a safety boundary. An external system having a bad day cannot corrupt the ledger, because nothing it sends reaches the ledger without passing through here.

Nothing arrives twice

Every inbox item carries a unique key derived from the transaction it represents. Feeds redeliver, webhooks retry and polling cursors overlap — this is normal behaviour, not a fault — so ingest is built to converge rather than duplicate. The same transaction arriving three times produces one item.

This matters more than it sounds. Duplicate ingest is the most common way an integrated ledger goes wrong, and it is usually discovered weeks later when a balance will not reconcile.

Working the queue

Items sit in the inbox until they are categorised and posted. In practice most are handled by rules and the queue contains only the exceptions. Aim to clear it before closing a period — an unprocessed inbox at close means the period is missing transactions that will have to be posted late.

Matching to existing documents

Where an incoming payment corresponds to an invoice already in the system, match it rather than posting it as a standalone transaction. The match is what settles the invoice and keeps the aged debt correct.

Items you cannot identify

Do not post a transaction you do not understand into a suspense account and move on — suspense accounts accumulate. Leave it in the inbox and ask. An unresolved item in a queue is visible; the same item buried in suspense is not.

Categorisation Rules

Rules turn a recurring incoming transaction into a coded posting without anyone looking at it. A monthly direct debit to the same supplier for the same purpose should not need a human decision twelve times a year.

Deterministic first

Rules are evaluated before any AI-assisted suggestion is considered. The ordering is deliberate and worth understanding: a rule you wrote produces the same answer every time and can be pointed at when someone asks why a transaction was coded a particular way. A suggestion is a guess, however good.

So anything you can express as a rule, express as a rule. Reserve assistance for the genuinely ambiguous residue, and treat its output as a proposal for a person to accept.

Writing a rule

A rule matches on what the incoming transaction contains — the counterparty, the reference, the amount, the direction — and sets what it should become: the account, and any analysis dimensions you use. Match on the most stable attribute available. A supplier's name in a bank narrative is more durable than a reference number that changes monthly.

Order and specificity

Put specific rules before general ones. A rule catching everything from one supplier will swallow the one transaction from that supplier that should have been treated differently, if it is evaluated first. Review the order whenever you add a rule, not only when something goes wrong.

Keep the set small

A rule set nobody understands is worse than no rules, because its mistakes are systematic. Periodically review which rules are actually firing and delete the ones that are not — a rule matching a supplier you stopped using two years ago is a trap waiting for a similarly-named new one.

Check what rules are doing

Sample automatically-coded transactions occasionally rather than assuming. The failure mode of a good rule set is not that it stops working; it is that it quietly keeps working after the underlying assumption changed.