Why AI Agents Need Double-Entry Accounting

A researcher's AI agent runs 40 overnight jobs. Each job calls an external API. Each API call costs between $0.04 and $2.31 depending on the data returned. At 6 AM, the system reports the agent spent $89.23.

The real number was $94.11.

The discrepancy: floating-point rounding accumulated across 40 concurrent balance updates. No single error was large enough to notice. The total was.

This is why financial infrastructure built for AI agents needs double-entry accounting — not as a compliance checkbox, but as the only correct way to track money that moves without human oversight.

What Double-Entry Accounting Actually Means

The principle is 500 years old. Luca Pacioli wrote it down in 1494. Every financial transaction affects at least two accounts, and the total debits must equal the total credits. Money doesn't appear or disappear — it moves.

When an agent pays $50 for an API call:

• The agent's wallet account is debited $50 (balance decreases)
• The expense account is credited $50 (expense recorded)

The ledger stays balanced. If those two numbers don't match, the transaction doesn't happen.

In practice, this means every payment through Wallgent creates two immutable ledger entries, linked by a shared transaction ID. The sum of all debits across all accounts always equals the sum of all credits. Always.

// What happens when an agent spends $50
const entries = [
  {
    accountId: 'acc_agent_operating',
    type: 'DEBIT',
    amount: '50.00000000',
    currency: 'USD',
    transactionId: 'txn_01HPKX4Y...'
  },
  {
    accountId: 'acc_EXPENSES',
    type: 'CREDIT',
    amount: '50.00000000',
    currency: 'USD',
    transactionId: 'txn_01HPKX4Y...'
  }
]

The database enforces this. A trigger fires on every insert and rolls back any transaction where debits ≠ credits. It's not application logic. It's a constraint that cannot be bypassed.

Why Floating-Point Breaks Autonomous Finance

Standard financial applications get away with imprecision because humans review transactions. A $0.01 rounding error gets caught at reconciliation. A human notices.

AI agents don't reconcile. They execute.

An agent that runs 10,000 transactions per month and accumulates $0.003 of floating-point error per transaction ends up with a $30 discrepancy in its balance. The agent doesn't know its balance is wrong. It makes spending decisions based on inaccurate data. Eventually, it tries to spend money it doesn't have.

Wallgent stores all amounts as decimal(20,8) strings — never as numbers. Eight decimal places of precision. No floating-point representation. The value "50.12345678" is stored exactly as that string, parsed by the database as a fixed-precision decimal.

// Amount is always a string, never a number
const wallet = await wg.wallets.getBalance('wal_01HPKX...')
// { available: "1024.50000000", pending: "0.00000000", currency: "USD" }

// Arithmetic in your code should use a decimal library
import Decimal from 'decimal.js'
const fee = new Decimal(wallet.available).mul('0.025') // exact

When you create a transaction via the API, amounts are validated as decimal strings before they touch the ledger. Pass a JavaScript number and you get a 400 error.

Immutability as a Trust Mechanism

The second property of the Wallgent ledger: entries are immutable. Once written, a ledger entry cannot be modified or deleted. This is enforced at the database level by triggers that detect any UPDATE or DELETE on the ledger_entries table and raise an exception.

This matters for autonomous agents for a specific reason: auditability.

When a human reviews what an agent spent, they need the historical record to be exactly what happened — not what someone decided to show them. If ledger entries could be modified, the audit trail would be worthless. You'd only know what the system was told to show you, not what actually occurred.

Mistakes are corrected with reversal entries, not edits:

// Reverse a transaction — creates new entries, not an edit
await wg.transactions.reverse('txn_01HPKX...', {
  reason: 'duplicate_charge',
  memo: 'Vendor charged twice for same request'
})

The original entries remain in the ledger. The reversal entries appear alongside them. The net effect is zero, and the complete history of both the error and the correction is preserved.

Concurrent Withdrawals and Lock Order

The problem double-entry accounting doesn't automatically solve: two agents spending from the same wallet at the same time.

Consider a research team that gives their agents shared access to a $500 operating wallet. Two agents simultaneously try to spend $300. Without proper locking, both transactions could read the same $500 balance, both see sufficient funds, and both complete — leaving the wallet $100 overdrawn.

Wallgent uses pessimistic locking with a deterministic lock order. When a transaction involves multiple accounts, those accounts are locked in ascending order by account ID before any balance is read. This prevents the deadlock scenario where agent A holds a lock on account X and waits for account Y, while agent B holds a lock on account Y and waits for account X.

The practical effect: one of those $300 withdrawals succeeds. The other returns an INSUFFICIENT_FUNDS error. The wallet never goes negative.

try {
  await wg.transfers.create({
    fromWalletId: 'wal_shared_ops',
    toWalletId: 'wal_vendor_payment',
    amount: '300.00',
    currency: 'USD'
  })
} catch (error) {
  if (error.code === 'INSUFFICIENT_FUNDS') {
    // The other agent got there first — adjust the task
    await scheduleForLater(task)
  }
}

Available vs Pending Balance

One more concept that matters for agents: the difference between available and pending balance.

When an agent initiates a payment, the funds move immediately into a pending state — deducted from the available balance but not yet settled. The agent's available balance reflects what it can actually spend right now.

const balance = await wg.wallets.getBalance('wal_01HPKX...')
// {
//   available: "200.00000000",  // what the agent can spend
//   pending: "50.00000000",     // authorized but not settled
//   total: "250.00000000"       // total value held
// }

An agent that plans its spending based on total instead of available will authorize transactions it cannot complete. The ledger treats these as two separate accounts (the available account and the pending account) with their own debit/credit pairs.

The Infrastructure Under Autonomous Finance

The reason these properties matter together: agents make decisions faster than humans can review them, and they don't have the social and legal accountability that makes human financial mistakes self-correcting.

A human who overspends feels the consequence. An agent doesn't. The infrastructure has to enforce correctness by construction.

Double-entry accounting ensures every dollar has a known origin and destination. Decimal precision ensures amounts are exact. Immutability ensures the history is trustworthy. Locking ensures concurrency doesn't produce impossible states.

These aren't features — they're the minimum viable foundation for a system that moves real money autonomously. The Wallgent ledger is built on all four. The sandbox environment at wallgent.com/playground lets you explore how this works with test transactions before you build with it.