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.

Where to find it

Architect Panel → ERP - Finance:

• Feed Providers — the adapters, all shipped disabled and without credentials
• Feed Connections — a provider bound to an entity and a ledger bank account
• Feed Events — webhook receipts, including ones that failed verification
• Accounting Code Map — how external codes map onto your chart of accounts

What ships, and in what state

Adapters are provided for the major accounting packages and bank connections. Every one ships disabled and without credentials, so nothing starts talking to an external service because an update was applied.

Setting one up

1. Enable the provider in Feed Providers and enter its credentials. The row follows the same shape as the platform's other external connections.
2. Create a row in Feed Connections binding it to a specific entity and a specific ledger bank account. This is what tells the system whose books an incoming transaction belongs to.
3. Map external codes to yours in Accounting Code Map.
4. Enable Accounting and Bank Feed Sync under Automation → Tasks, hourly.
5. 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; sharing one means inferring it from the transaction, which is exactly the kind of guess that produces a misposted month.

Failed webhooks are recorded too

Feed Events records every webhook received — 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 your endpoint, and neither is visible if failures are silently discarded. Check here when a provider insists it sent something you cannot find.

Credentials

Feed credentials permit reading your financial data. Give the connection its own rather than reusing a person's login, so access survives somebody leaving and can be revoked without breaking a human's access.

Worked example

A company with two entities and three bank accounts creates three connections: one per bank account, each bound to the right entity and the matching ledger account. When the second entity's account is later moved to a different bank, only that connection changes — the other two are untouched, and no historical transaction is re-attributed.

Recommendations

• One connection per bank account, always.
• Use service credentials, never a person's.
• Check Feed Events after go-live — a burst of verification failures is worth knowing about on day one.
• Confirm nothing posts straight through before you trust the connection.

The Feed Inbox and Queue

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

Where to find it

Architect Panel → ERP - Finance:

• Feed Queue — the console — review, code and post what has arrived
• Feed Inbox — the underlying staged rows
• Accounting Periods — the close the queue must be clear for

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 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 commonest way an integrated ledger goes wrong, and it is usually discovered weeks later when a balance will not reconcile and nobody can say why.

Working the queue

In practice most items are handled by rules and the queue holds 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 into the next one.

Matching to existing documents

Where an incoming payment corresponds to an invoice already in the system, match it rather than posting a standalone transaction. The match is what settles the invoice and keeps the aged debt correct; posting it separately leaves the invoice apparently unpaid and the bank reconciled.

Items you cannot identify

Do not post a transaction you do not understand into suspense and move on — suspense accounts accumulate, and the accumulation is somebody's year-end problem.

Leave it in the queue and ask. An unresolved item in a visible queue gets chased; the same item buried in suspense does not.

Worked example

A month's bank feed brings 340 transactions. Rules code 310 of them automatically. Of the remaining 30, 22 are matched to sales invoices, six are coded by hand, and two are genuinely unrecognised — so they stay in the queue and the bookkeeper emails the office manager. The period is not closed until those two are resolved.

Recommendations

• Make clearing the queue a pre-close step, and check it as one.
• Match payments to invoices rather than posting them separately.
• Never use suspense as a queue.
• Review the queue daily if volumes are high — a backlog is much harder to work than a day's worth.

Coding Rules and the Outbound Mirror

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

Where to find it

Architect Panel → ERP - Finance:

• Accounting Code Map — the coding rules
• Accounting Outbox — postings queued for an external package
• Feed Queue — where unmatched items surface

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 somebody asks why a transaction was coded a particular way. A suggestion is a guess, however good — and "the system suggested it" is not an answer an auditor accepts.

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, and it will do so silently. 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 rather than occasional. 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.

The outbound mirror

Where you keep an external accounting package alongside the ledger, Accounting Outbox queues postings to be pushed out, driven by the Accounting Outbound Mirror task.

This is a mirror, not a handover — the ledger remains the system of record. Watch the outbox for items failing repeatedly; they usually mean a code mapping the external package will not accept, and each retry is time you may not have before a filing deadline.

Worked example

A business writes eleven rules covering rent, utilities, insurance, payroll and its five largest suppliers. Those cover about 80% of bank volume. The remaining 20% is worked by hand each week, and any transaction appearing three times by hand becomes rule twelve.

Recommendations

• Write a rule when a manual coding recurs three times, not before.
• Specific before general, and re-check the order on every addition.
• Sample automatically-coded items occasionally — a good rule set fails by quietly continuing after an assumption changed.
• Investigate a second outbox failure rather than retrying.