Skip to main content
Every transaction you report in the daily Transactions file carries a classification that Lead uses for accounting entries, account reconciliation, and ongoing program oversight. This page is the semantic reference for that classification; the field-by-field schema lives in the File Reference.
Map your ledger’s transactions to Lead’s transaction types before going live — the mapping must be approved by Lead’s accounting team, and your implementation team will provide a tool for completing this request during onboarding. If activity in your ledger doesn’t fit a type below, raise it during mapping rather than bending a type to fit.

The Four-Field Classification

A reversal is a new transaction with action: reversed — you never delete or mutate a previously reported record. Note the polarity flip per type in the tables below: a reversal moves the balance in the opposite direction of the corresponding applied transaction. Corrections to fields like settlement_date on an already-reported transaction go through the Transactions Updates file instead.

Transfer Types

If the transaction was conducted via a Lead API or payment rail, also provide transfer_ids on the record — the Lead-generated transfer object IDs (e.g., the ACH ID) that tie your reported customer activity to the money movement Lead executed. transfer_type is required for these types (optional elsewhere — any valid enum may be provided):
  • Deposit balances: debit, credit, refund, dispute_provisional, escheatment
  • Credit balances: disbursement, payment, refund, client_credit, dispute_provisional

Deposit Transaction Types

Polarity is from the balance’s perspective: positive increases the deposit balance, negative decreases it.

Credit Transaction Types

Every credit transaction must include amount = principal_amount + fee_amount + interest_amount — the same decomposition the Balance’s live position tracks and reconciliation asserts. If your program offers rewards, the rewards fields are also required.
Polarity is from the balance’s perspective — the balance is what the customer owes, so draws are positive and payments negative.
All three dispute types (dispute_provisional, dispute_won, dispute_lost) support both applied and reversed: a reversed transaction unwinds a previously reported dispute transaction of the same type, moving balance and dispute_balance in the opposite direction of the corresponding applied transaction.

Reference

Transactions Schema — every field, requiredness, and data types, including transfer_ids, funding_id, original_transaction_id, and the per-type settlement_date rules · Balance Reconciliation — the identities these classifications feed · Balances & Transactions Files Troubleshooting — the validation errors and fixes.