Pulling Intuit Business Credit Card transactions, balances and rewards into your own systems

Every charge on an Intuit Business Credit Card posts automatically into the cardholder's QuickBooks Online company, which is the single detail that decides how a third-party system should read this account. The same data the app puts on screen — current balance, available credit, posted and pending transactions, the 2% and 5% cash-back accruals, and a list of employee cardholders — is what an integrator wants to mirror somewhere else: an expense tool, a treasury dashboard, a custom ledger. Our job is to get that data out, kept current, under the account holder's own authorization. The card is issued by WebBank and serviced by Intuit, per Intuit's card page, so the records sit on Intuit's card-servicing backend rather than at a separate bank you would query directly.

Where the data lives and what it is good for

The app names its surfaces plainly. Here is each one mapped to where it originates and what an integration does with it.

Authorized routes to the account

Three approaches fit this account, and they combine well rather than competing.

Consented authorization to the synced ledger

Because charges auto-post into the cardholder's QuickBooks Online company, a consenting account holder can authorize access to that company. The mechanism is an OAuth 2.0 and OpenID Connect authorization-code grant, scoped to a realm id, with a refresh token that lives roughly 100 days before re-authorization (per Intuit's developer documentation). This reaches the posted transaction history cleanly and durably. We handle the consent and registration with you during onboarding.

Reading the app account directly

Authorized interface integration of the card app's own traffic reaches everything on screen, including the parts that never reach QuickBooks: pending transactions before they settle, the live available-credit figure, the rewards accrual, the cardholder roster, and card-control state. This route tracks the app's client contract, so we re-validate it whenever the app changes. Effort is higher than the consented route; the payoff is full surface coverage.

Native export as a fallback

Where a cardholder can download a statement or transaction export, we parse and normalize it. Coverage is coarse — cycle-level, no pending rows, no real-time — but it is a low-effort backstop when a live feed is not warranted.

For most builds we lean on the consented route for the posted history, because it is durable and clean, and read the app account directly for the pending, balance, rewards and cardholder surfaces that do not sync downstream. The export path stays in reserve.

Delta-syncing the transaction feed

The account is busiest where it matters least for batch jobs: pending entries appear and then change at settlement. A delta pull keyed on a cursor handles that without re-reading the whole history each time. The shape below is illustrative — field names and the cursor contract are confirmed during the build, not lifted from a published spec.

# Delta pull against the card account's transaction surface.
# Shape illustrative; confirmed during the build.
GET /accounts/{account_id}/transactions?updated_since={cursor}&include=pending
Authorization: Bearer {access_token}          # token session, refreshed before it lapses

-> 200 OK
{
  "cursor": "2026-06-15T14:02:11Z:txn_8f21",   # high-water mark for the next pull
  "transactions": [
    { "id": "txn_8f21", "status": "pending", "amount": -128.40, "currency": "USD",
      "merchant": "...", "cardholder_id": "ch_3", "posted_at": null },
    { "id": "txn_8e02", "status": "posted",  "amount": -2400.00, "currency": "USD",
      "merchant": "...", "cardholder_id": "ch_1", "posted_at": "2026-06-14T09:11:02Z" }
  ]
}

# An entry first seen "pending" and later "posted" carries the same id.
# Fold the settled amount and merchant into the existing row; persist the
# cursor and send it back on the next poll. No full-history rescan.

A normalized shape for the records

Downstream systems want one consistent model, not the app's wire format. We map the surfaces into a small set of records like these.

Transaction {
  id, cardholder_id, status: pending|posted, amount, currency,
  merchant, mcc?, posted_at?, statement_cycle?
}
Cardholder {
  id, name, card_type: physical|virtual, spend_limit, state: active|frozen
}
RewardAccrual {
  id, source_txn_id?, rate: 0.02|0.05, amount, cycle, kind: statement_credit
}

What you get from us

The deliverable for this account leads with code that runs.

• Runnable source in Python and Node.js for the delta-sync pull, the pending-to-posted reconciler, and a persisted cursor store you can point at your own database.
• A normalized data model — transactions, cardholders, statements, reward accruals — ready to map onto your schema.
• An automated test suite with fixtures for the pending-to-posted transition and a multi-cardholder spend split, so a behavior change shows up against a known baseline.
• A scheduled sync runner, queue- and cron-friendly, with re-authorization handled around the consent window.
• An OpenAPI description of the surfaces we touched and an auth-flow write-up covering the OAuth 2.0 and OpenID Connect token chain.
• Interface documentation plus data-retention and consent-record notes for your compliance file.

Authorization, consent and where the rules stand

The dependable basis for this work is the cardholder's own authorization: the account holder consents to a downstream copy of data that is already theirs. Intuit services the card and WebBank is the issuer of record, per Intuit's card page, so any access runs against the consenting account, logged, with fields minimized to what a given job needs and an NDA where the work touches sensitive records. At the federal level, the CFPB's Personal Financial Data Rights rule under Section 1033 is the piece to watch rather than rely on — its compliance dates are stayed and the Bureau reopened it for reconsideration in 2025, so it points to where a standardized consumer data-access right may settle, not to a present obligation. We build to consent today and track 1033 as it moves.

Details we plan around

Two things about this account shape the build, and we account for both.

Pending entries are provisional. The app shows a charge as pending before it settles, and the amount or merchant can change when it posts. We treat a transaction as provisional until its status flips, then fold the settled values into the existing row, so a copy of the ledger does not carry stale pending figures or a duplicate posted line. A naive append-only pull gets this wrong.

Spend is multi-cardholder by design. The account is a parent with employee sub-cards — physical and virtual, each with its own spend limit. We model the account as a parent and a set of cardholder sub-cards so attribution and limit state live per person, which is what makes per-employee reporting and limit enforcement work rather than a single blended balance.

On the consented route, the refresh token has a finite life (about 100 days, per Intuit's developer docs). We schedule re-authorization ahead of that boundary so the feed keeps flowing instead of quietly stalling. Access, registration and any sandbox or consenting test account are arranged with you during onboarding.

What the app screens show

Store screenshots, useful for confirming which surfaces exist before a build. Tap to enlarge.

Sources we checked

This mapping rests on the app's own listing and Intuit's published material, read against the current US data-rights position. We confirmed the card program, rewards mechanics and account surfaces on Intuit's card page and the Google Play listing; the token lifetimes and grant type against Intuit's OAuth 2.0 documentation; and the Section 1033 status against the CFPB reconsideration notice. Field mapping and route notes by OpenFinance Lab, last checked 15 June 2026.

Other cards and spend platforms in the same space

A unified integration usually spans several of these, since a business rarely runs on one card program. Each holds account-level data a sync would touch.

• Brex — corporate cards with spend management; holds transactions, balances and expense records across teams.
• Ramp — corporate card and expense platform; flat-rate cash back, receipts and per-transaction data.
• Mercury IO — a Mastercard tied to account balances, with virtual cards and spend controls.
• BILL Divvy — budgets, virtual cards and an expense ledger joined to accounts payable.
• Capital One Spark — a traditional business rewards card with statements and transaction history.
• Chase Ink — bank-issued business cards carrying transactions, statements and rewards.
• American Express Business — business charge and credit cards with a spend and rewards ledger.
• Rho — corporate cards alongside treasury and banking, with spend controls and statements.

Questions we get about this one

How often does the Intuit Business Credit Card ledger change, and how do you keep a copy current?

Posted balances move when charges settle, and the app surfaces pending transactions that can shift through the day. We run a cursor-based delta pull that asks only for what changed since the last marker, reconciles each entry as it moves from pending to posted, and re-authorizes ahead of the consent window so the feed stays live. Cadence is tuned to how busy the account is rather than a fixed clock.

Can you split spending by individual cardholder or employee virtual card?

Yes. The account is a parent with any number of cardholder sub-cards, each with its own physical or virtual card and spend limit, so we model spend attribution and limit state per cardholder rather than collapsing everything into one balance.

The cash back posts as a statement credit — how is that represented?

The 2% and 5% cash back land as statement credits against the card rather than a separate wallet, per the app and Intuit card page. We record each accrual as a dated ledger entry tied to its cycle so reward credits are not mistaken for spend or for a payment.

Can the QuickBooks-synced transactions be used instead of reading the app directly?

Often, yes, and it is usually the cleaner path. Every charge posts automatically into the cardholder's QuickBooks Online company, so with the account holder's consent we authorize against that company through an OAuth 2.0 and OpenID Connect grant. Surfaces that do not sync there — pending entries, available credit, rewards accrual, cardholder controls — come from reading the app account directly under the same authorization.

Source code for the surfaces above starts at $300, billed only after it is delivered and you are satisfied; or skip the build and call our hosted endpoints, paying per call with nothing upfront. Either path typically wraps inside one to two weeks. Send the app name and what you need from its data at our contact page.