GUIDE
Bank feeds 101 for card and spend platforms
How bank feeds work in QuickBooks Online and Xero, feed partner programs, data quality rules and reconciliation UX for card and spend platforms.
By Unify Int teamUpdated 7 min read
If you run a corporate card, a spend management tool or a neobank for businesses, your customers' accountants want your transactions in their ledger. Without a feed, someone exports a CSV every week, uploads it into QuickBooks Online or Xero, fixes the columns, and hopes nothing was imported twice. A bank feed replaces that with a steady stream of transactions that arrive ready to reconcile.
This guide covers how bank feeds work, what the major ledgers expect, the data quality rules that decide whether accountants trust your feed, and the reconciliation experience to design for.
What a bank feed is
A bank feed is a stream of account transactions sent from a financial institution or card provider into accounting software. In the ledger, each feed is attached to a bank or credit card account. Transactions arrive in a queue, and the bookkeeper matches each one to an existing record (an invoice payment, a bill payment, a transfer) or creates a new one, such as an expense with an account and tax code.
The feed does not create journal entries on its own. It creates statement lines: the evidence of what happened in the account. Reconciliation turns those lines into accounting. That separation matters for your design. Your job is to send accurate, complete, well-described lines. The ledger and the bookkeeper do the rest.
Bank feed versus bank data
The terms get confused, so it helps to be precise:
- Bank feed (push). You send transactions into a ledger. This is what card and spend platforms need.
- Bank account data (pull). You read balances and transactions from a bank, usually through an open banking or data aggregation provider. Lenders and cash-management tools need this.
Some products need both: read a customer's bank transactions from a data provider, then push them into the ledger.
How feeds work in QuickBooks Online and Xero
Both ledgers support feeds from third parties, and both control who may send them. The details change over time, so treat this section as orientation and confirm the current requirements in each vendor's documentation before planning a launch.
Xero
Xero offers a Bank Feeds API for financial institutions and card providers. Access is not open to every app: providers apply to Xero and need approval before sending feeds to customers' organizations. Expect a review of your use case, your data and your connection experience, and allow for that in your timeline.
Once approved, the flow typically looks like this: the customer authorizes your app, you create a feed connection that links one of your accounts to a bank account in their Xero organization, and you post statements made of statement lines. Each line carries a date, an amount, a credit or debit indicator, a description and identifiers.
QuickBooks Online
Intuit also runs a process for institutions and providers that want to send transactions into QuickBooks Online bank feeds. As with Xero, it involves an application and review, and the exact route depends on the kind of provider you are. Intuit's partner documentation is the source of truth for which program applies to you.
From the customer's side, a connected feed appears as a bank or credit card account in the banking area, with incoming transactions waiting to be categorized or matched.
Other ledgers
Sage Accounting, MYOB and FreshBooks each have their own approach to third-party feeds, from formal programs to statement imports. NetSuite customers often rely on bank statement import formats rather than a push feed. Check per ledger; coverage is not uniform.
Feed accounts
Every feed starts with a feed account: the account in your system that maps to an account in the customer's ledger.
Decide early how you model them:
- One feed per card or per company account? Bookkeepers usually prefer one ledger account per real account. For cards, that can mean one feed per cardholder, which gets noisy fast. Many providers send one feed per company card program and include the cardholder in the description.
- Currency. A feed account has one currency. Multi-currency cards need one feed per settlement currency.
- Account type. Card spend belongs in a credit card account; deposits and transfers belong in a bank account. Getting this wrong flips signs and confuses reconciliation.
Creating a feed account looks like this in a unified API:
curl -X POST "https://api.unifyint.com/v1/finance/bank-feeds" \
-H "Authorization: Bearer $UNIFY_API_KEY" \
-H "Unify-Connection-Id: conn_xro_3m9d7" \
-H "Idempotency-Key: feed-acct-card-program-01" \
-H "Content-Type: application/json" \
-d '{
"name": "Company card ending 4417",
"type": "credit_card",
"currency": "USD",
"account_number_last4": "4417"
}'Transaction fields that matter
Each transaction you send should carry the following.
| Field | Why it matters |
|---|---|
| Unique transaction id | Lets the ledger and your system detect duplicates. Never reuse an id. |
| Posted date | The date the transaction settled. Use the account's local date, not UTC midnight. |
| Amount | Always as a decimal string, in the feed's currency. |
| Direction | Debit or credit, either as a sign or an explicit indicator, depending on the target API. |
| Description | What the bookkeeper reads first. Merchant name, not processor codes. |
| Payee | The merchant or counterparty, cleaned. |
| Reference or memo | Cardholder, receipt id, expense report id. |
| Running balance | Optional on some ledgers, required on others; lets bookkeepers check the feed against a statement. |
Sign conventions
This is where feeds go wrong most often. Some APIs take a signed amount, where negative means money out. Others take a positive amount plus a credit or debit indicator. For a credit card account, a purchase increases what is owed; for a bank account, a purchase reduces the balance. Define your convention once, convert at the edge for each ledger, and test both account types in each ledger's sandbox before you send real data.
Pushing a transaction:
curl -X POST "https://api.unifyint.com/v1/finance/bank-feeds/bfa_01JCA2M8QX/transactions" \
-H "Authorization: Bearer $UNIFY_API_KEY" \
-H "Unify-Connection-Id: conn_xro_3m9d7" \
-H "Idempotency-Key: txn_9F3K22LQ" \
-H "Content-Type: application/json" \
-d '{
"transactions": [
{
"id": "txn_9F3K22LQ",
"posted_date": "2026-10-28",
"amount": "84.20",
"direction": "debit",
"description": "Harbor Supply Co.",
"payee": "Harbor Supply Co.",
"memo": "Card 4417 · J. Rivera · receipt rcpt_77Q2"
}
]
}'No duplicates, no gaps
Accountants forgive a lot, but not duplicate lines and not missing days. Both break reconciliation.
Idempotency
Use your transaction id as the idempotency key for every line, and make retries safe at every layer. If a request times out, you should be able to send the same batch again without creating a second line. Ledgers vary in how strictly they enforce uniqueness on their side, so do not rely on them alone.
Pending versus posted
Send posted transactions only, unless the ledger explicitly supports pending lines. A pending authorization that later settles for a different amount, or drops, creates a line the bookkeeper cannot reconcile.
Gap detection
Track the last date you successfully delivered for each feed account. If a day is missing, because of an outage, an expired token or a rejected batch, flag it and backfill it. Run a daily check that compares the transactions you hold with the transactions the ledger has accepted.
Backfill limits
When a customer first connects, they will want history. How far back you can send depends on the ledger and sometimes on the feed program; limits differ, and they change. Check each ledger's current rules, tell the customer the limit in your connection flow, and avoid backfilling beyond the period their books are already closed for.
Data quality rules
A feed is only as good as its descriptions. Rules worth adopting:
- Clean merchant names. "Harbor Supply Co." beats "HRBR SPLY*4471 SEATTLE WA".
- One line per real transaction. Do not split or merge unless the source did.
- Refunds as their own lines. Link them to the original in the memo.
- Fees as separate lines. Foreign exchange and card fees belong in their own expense account.
- Stable descriptions. Do not rewrite a description after sending it; bank rules in the ledger may depend on it.
- Local dates. A purchase at 11 pm should not land on the next day.
Reconciliation UX in your product
The best feeds make reconciliation feel like checking, not data entry.
- Show connection status in your product: connected, last delivered date, errors.
- Explain the mapping. Which card or account feeds which ledger account.
- Send receipts and categories where supported, so bookkeepers have the evidence in one place.
- Surface rejections. If the ledger rejects a line, show why and let the customer fix the cause.
- Make reconnects easy. Tokens expire. A single button to reconnect saves a support ticket.
Launch checklist
- Feed partner approval confirmed for each ledger, per current vendor docs.
- Account type and sign convention tested in each ledger's sandbox.
- Idempotent delivery with retries.
- Gap detection and backfill.
- Clean descriptions and payees.
- Customer-facing status and reconnect flow.
- Support runbook for "my transactions are missing".
How Unify Int fits
The Unify Bank Feeds API is designed for card issuers, neobanks and spend platforms: create feed accounts and push transactions into QuickBooks Online, Xero and other ledgers through one API, with idempotent transaction ids, gap detection and backfill. Payments and accounting data sit on the same Unify Graph, so your product can read what was reconciled through the Accounting API. Where a ledger runs a partner program for feeds, the Unify Technology Center can help with the application and certification steps. Check per-ledger status on the coverage matrix, or book a demo.