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

Enable the provider in Feed Providers and enter its credentials. The row follows the same shape as the platform's other external connections.
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.
Map external codes to yours in Accounting Code Map.
Enable Accounting and Bank Feed Sync under Automation → Tasks, hourly.
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.