Account Balance

An account can be either a debit account or a credit account. A debit account is normally not allowed to go below 0. A credit account typically starts at 0 and may go negative until repaid.

The source of truth for the Account Balance of an account is the associated Ledger. The Ledger does not own or store any limits of the account. Instead applicable limits are passed by the caller (The implementor of the ITransactionProcessorGateway interface). Account specific balance limits are configured on the Majority Accountin the Wallet. General limits are configured in Transactions.

Available Balance

Alternative name (debit context): Disposable Balance

The amount currently available to spend. For a credit account, this will normally be a negative amount (representing used credit).

Formula:
Available Balance = Posted Balance - Reserved Amount

Posted Balance

Alternative names: Total Balance, Ledger Balance

The actual amount recorded on the account. For a credit account, this will normally be a negative amount.

Reserved Amount

Alternative names: Reserved Balance

The portion of the Posted Balance that is not available to spend.

Note that crypto account does not support reservations, and therefor the Reserved Amount will always be 0 for a crypto account.

Formula:
Reserved Amount = Posted Balance - Available Balance

Disposable Balance

For a debit account:
Disposable Balance = Available Balance

For a credit account:
Disposable Balance = Available Balance + Credit Limit

(For debit accounts, Credit Limit is effectively 0.)

Used Credit

For a credit account, this is the inverse (negation) of the Posted Balance.

Formula:
Used Credit = -Posted Balance

Credit Limit

While not strictly part of the Account Balance, the Credit Limit is part of the Balance model in Firebase and is therefore listed here.

For a credit account, this is how much credit is granted (e.g., 100). It defines how far below zero the Available Balance is allowed to go.

Constraint:
Available Balance >= -Credit Limit

Examples

Below are illustrative (simplified) scenarios showing how common transaction events impact the three core figures

Legend

PB = Posted Balance
RA = Reserved Amount
AB = Available Balance (PB - RA)
CL = Credit Limit (credit accounts only)
UC = Used Credit ( -AB on credit accounts)
DB = Disposable Balance (AB + CL on credit accounts)

---

1. Debit Account Scenario

Assume a debit (deposit) account that cannot go below 0.

Time	Event	Explanation	PB	RA	AB
0	Starting point	Funds already in account	100	0	100
1	Card authorization for 30	Places a hold; no posting yet	100	30	70
2	Second card authorization for 20	Another hold added	100	50	50
3	First authorization captures (settles) 30	Hold released & ledger posts the 30 spend	70	20	50
4	Second authorization partially captures 10 (remaining 10 released)	PB reduced by 10; 10 of hold released	60	0	60
5	Refund / reversal of 15 (posted)	Refund increases PB	75	0	75
6	New authorization for 80 (declined)	Hold of 80 would leave AB = -5 so it is declined	75	0	75

---

2. Credit Account Scenario

Assume a credit account with a Credit Limit (CL) of 300. Negative PB indicates owed amount. The Available Balance is typically negative (representing used credit); constraint: AB >= -CL.

Time	Event	Explanation	PB	RA	AB	UC	DB
0	Starting point	No activity	0	0	0	0	300
1	Purchase posts 80 (no prior auth shown)	Direct post (or prior auth already cleared)	-80	0	-80	80	220
2	New authorization 40 pending	Hold reduces availability further	-80	40	-120	80	180
3	Authorization captures 25 (partial)	25 added to PB; hold left 15	-105	15	-120	105	180
4	Remaining 15 hold expires (not captured)	Hold released	-105	0	-105	105	195
5	Refund / credit of 20 posts	Reduces owed amount	-85	0	-85	85	215
6	Large authorization 230 (declined)	Would set AB = -315 (< -300) so it is declined	-85	0	-85	85	215