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.