Skip to content

Balances

GIB exposes a pending and an available balance on every account and every virtual account, retrieved via the Balance API: getBalance for a core account, getBalanceVirtual for a virtual account. Both return point-in-time values; for historical reconstruction, query transactions by date range and sum.

Underlying each, transactions move through memo-posted and hard-posted states as they settle. See Transactions → Lifecycle for the full state model.

Disclaimer: The balance values exposed through the API represent GIB's current system-of-record view, including pending, memo-posted, and hard-posted transactions. These values are informational and provided to assist you in operating your program. Depending on your agreement with GIB, you may be solely responsible for determining and maintaining accurate balances for your end users. The API-reported balances do not replace, amend, or supersede any obligations in your contract and, unless otherwise noted, should not be relied upon as the authoritative balance for reconciliation or compliance purposes.

Pending balance

The pending balance is the sum of every transaction GIB is currently tracking that has not yet posted to the bank's core. It includes:

  • Same-day or next-day ACH transactions submitted but not yet settled
  • Wires submitted but not yet through Federal Reserve settlement
  • ICL deposits submitted but not yet posted

The pending balance is forward-looking. It tells you what the available balance will be once tracked transactions complete, assuming none return.

The balance API returns pending balance separately for debits and credits as pending_balance_credit and pending_balance_debit (in cents).

Available balance

The available balance is the sum of all transactions that have posted to the bank's core, minus any holds. It's the balance against which NACHA computes overdrafts and the balance from which outbound transactions can be drawn.

The available balance combines:

  • All hard-posted transactions
  • All memo-posted transactions
  • Less any holds (e.g. Reg CC holds on deposited checks)

The balance API returns available balance separately for debits and credits as available_balance_credit and available_balance_debit (in cents).

Memo-posted vs. hard-posted

Within "posted," GIB recognizes a further distinction:

State When Behavior
Memo-posted Same business day a transaction posts Counts toward available balance; not yet finalized in the year-end ledger
Hard-posted At end-of-day rollover into the historical ledger The terminal posted state; immutable

Both memo-posted and hard-posted transactions count toward the available balance. The distinction matters mostly for end-of-day reporting and for reconciliation, at the 5:40 PM CT cutoff, memo-posted transactions move to hard-posted.

ACH-specific timing

For ACH transactions, the path from pending → available follows the ACH lifecycle:

  1. Transaction submitted → pending balance reflects it
  2. ACH submitted to Fed → still pending
  3. Fed confirms → still pending until settlement window
  4. Settlement window completes → memo-posted; available balance reflects it
  5. End of day → hard-posted; ledger finalized

For BOOK transfers, pending → available happens within the same business day's processing window.

For wires, settlement is real-time during Federal Reserve operating hours, so pending → available happens within seconds.

For ICL (check), Reg CC holds delay the move from posted to available. Checks post as one deposit per deposit ticket, not one per check.