Skip to main content
You hold accounts for your end-users: a business account, a wallet, a card account or a balance with your payment service. Money comes in and goes out of those accounts every day. Your end-users want every one of those movements to appear automatically in their accounting software, so their books always show the same balance as the real account. This is what a bank feed does. It sends the movements of an account to the accounting software, the way a bank sends a statement. This article explains what happens to those movements once they arrive, what your end-users configure, and what you build. You do not need an accounting background. The people who own the books make the accounting decisions.

Why it matters

In accounting, every real account your end-user holds is represented by a bank account in their books. At the end of each period, both must show exactly the same balance, and every movement must have an accounting explanation. Checking this is called bank reconciliation: going through the account’s movements one by one and linking each to what it was for. Without a bank feed, someone has to type the movements in or import statement files by hand. With a bank feed, the movements arrive on their own, every day, and reconciliation becomes the only remaining step.

The movements involved

A bank feed sends every settled movement of the account, whatever it is: Each movement arrives as one line on a daily statement for that account, with its amount, date, description and, when known, the counterparty.

The bank feed and the other parallel flows in the accounting

A bank feed tells the accounting software that money moved. It rarely tells it what the money was for. That part usually comes from another flow such as expense or invoice booking, which records the accounting document behind the movement: The two meet during reconciliation, in the accounting software: each line is matched to its document, so every movement is booked once. The document books what it was, and the line proves it was paid. The next section shows how this works. Two rules follow from this:
  • The bank feed sends every movement, even those that already have an accounting document. Leaving a line out because a bill or an expense already exists breaks the balance, and leaves that document unpaid in the books.
  • The other flows never record the money themselves. The money always comes from the bank feed, so nothing is counted twice.
The order does not matter. An accounting document can arrive before or after its line. Clear descriptions and references on each line, such as an invoice or expense number, help the accounting software suggest the right match.

What happens in the accounting software

A statement line is not yet an accounting entry. It is evidence that money moved. The accounting software places it in its reconciliation area, a waiting list of lines to explain. Nothing changes in the books until someone, or a rule, explains the line. Each line is explained in one of three ways:

Example: a customer payment matched to its invoice

In the examples below, each row is a ledger account: a heading in the books where amounts of one kind are added up, such as the bank, a customer or bank fees. Account numbers follow the Belgian chart of accounts as an illustration. They differ from one country, and one accounting software, to another. Your end-user sent their customer an invoice for €480.00. It is already in their books, unpaid. The customer pays, and the line +€480.00 arrives through the bank feed. Your end-user matches it to the invoice. The accounting software records the payment: The revenue and the VAT were booked when the invoice was created. Matching does not book them again. It only records that the money has arrived.

Example: a fee coded to an account

Your service takes a fee of €6.72 from the account. No invoice or bill exists for it: the statement line is the evidence. A rule your end-user set up codes it to their bank fees: In both cases, you never build these entries. The accounting software creates them when the line is reconciled.

A complete and balanced statement

For the books to match the real account, the statement must be complete. Each statement covers one account and one day. It lists every settled movement once, and starts from the account’s opening balance: opening balance + all movements of the day = closing balance When this holds, the accounting software can show at any time whether its balance and the real account’s balance agree. Any difference points to a line that is still waiting to be reconciled.
Only settled movements belong on a statement. A payment that is still pending is sent once it has settled, so it is never sent twice.

What gets configured by the end-user

Who configures what. Your end-user, or their accountant, makes the accounting choices: which bank account in their books each of your accounts feeds, when the feed starts, and how lines are explained during reconciliation. They know their own books; you never make these choices. They make the first two in a setup screen. You build this screen with the Unified API, or Chift provides it with a Sync (see What you build). Reconciliation itself happens in their accounting software.

Which bank account each of your accounts feeds

Each account you hold for your end-user, and each currency of it, feeds one bank account in their books. Your end-user picks it from the bank accounts in their accounting software, or creates a new one. Each bank account receives the statements of one account and one currency only.

When the feed starts

Your end-user chooses the first day the feed covers. It should start right after the last movement already in their books, whether it was typed in or imported from a file. Starting earlier would bring the same movements in twice. If movements from this account are already imported another way, for example through a separate bank connection or statement files, that import must stop when the feed starts. Two sources for one account book every movement twice.

How lines are explained

Reconciliation happens in your end-user’s accounting software. For recurring movements, such as your fees, they can set up a rule once so that every similar line is coded automatically. Everything else is matched to its document, or explained by their accountant.

What you build

Your end-user always makes the accounting choices above: which bank account each of your accounts feeds, when the feed starts, and how lines are reconciled. These are decisions about their own books, not yours. You build the integration around those choices. What you build depends on how you connect to Chift. With the Unified API, you build it yourself:
  • a setup screen where your end-user links each of your accounts, per currency, to a bank account in their books, or creates one, and chooses the start date;
  • send logic that sends one statement per account and per day, with every settled movement once, the opening balance, and a clear description and reference on each line;
  • a balance check before sending: the opening balance plus the movements must give the account’s real closing balance;
  • logic that prevents duplicate statements when a sync runs more than once or a request is retried.
With a Sync, Chift builds it for you. Chift’s Banking sync provides the setup screen, where your end-user links each account to a bank account in their books, and sends the statements on a schedule. You build neither the screen nor the sending logic.