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.