flintDocs

Reconciliation

Reconciliation answers two questions: what did this deposit consist of, and does what we collected match what we recorded? Flint's ledger is built for both. Every movement of your balance is a balance transaction carrying a gross amount, a fee, a net, and a link back to the object that caused it.

For what Flint charges to process a payment, see Processing fees.

The ledger is the source of truth#

Order totals tell you what a buyer owed. Balance transactions tell you what reached your balance, which is the number that has to match your bank.

Each entry carries three signed amounts:

  • amount_money: the gross movement.
  • fee_money: Flint's fee on it: positive for a charge, negative for a returned fee, and zero when no fee applies.
  • net_money: the real effect on your balance.

At API version 2026-09-07, subtract the fee from the gross amount:

Text
net_money = amount_money - fee_money
5000 gross - 175 fee = 4825 net
cURL
curl "https://api.withflintpay.com/v1/balance-transactions?created_after=2026-07-01T00:00:00Z&page_size=50" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Flint-Version: 2026-09-07"

Summing net_money over a set of transactions gives you what those events did to your balance. Do not subtract fee_money afterward: net_money already accounts for it.

order_id is present when the movement belongs to an order. related_resource points back to the object that produced the entry for payment, refund, payout, and payout destination movements. Dispute movements carry no related_resource today, so match those by order_id and occurred_at against the dispute itself.

What each movement type means#

type tells you what a row is. Filter on it rather than inferring from the sign, because more than one type can post negative.

  • payment posts positive, with fee_money carrying the processing fee. Net is what the payment added to your balance.
  • refund posts negative for the principal only. The original payment's processing fee is not returned, so a refunded payment leaves you down that fee. See Refunds.
  • dispute posts negative for the disputed principal only, so its fee_money is 0. Any event fee is assessed through Flint billing instead of this ledger. dispute_reversal posts positive when you win. See Disputes.
  • return posts negative when a payment that already settled is pulled back afterward, such as an ACH return. Its fee_money is 0; any ACH return event fee appears in Flint billing. recovery posts positive when a refund fails and the money comes back to you.
  • payout posts negative: money leaving your Flint balance for your bank. payout_failure, payout_cancellation, and payout_reversal return the money when a deposit does not land.
  • payout_hold and payout_hold_release move funds into and out of a pending payout. They are internal to the payout lifecycle, not new money, so a period that contains a hold without its release will not tie out on its own.
  • reserve_hold and reserve_release move funds into and out of a held reserve. Like payout holds, they change what is available without changing what you earned.
  • payout_advance and payout_advance_funding cover an advance of funds and the repayment that funds it. Most integrations never see them.
  • merchant_billing_payment posts negative when Flint collects what you owe Flint out of your balance. fee_money is zero, so net equals the gross. merchant_billing_payment_reversal posts positive when one of those collections comes back, and its related_balance_transaction_ids names the collection it reverses. See Flint billing.
  • adjustment is the catch-all for a correction posted against your balance. Read description to see what it covers.

Corrections are always appended as new dated rows. Flint never rewrites a settled amount, so a row you already reconciled will not change under you.

Matching a deposit#

A payout is the deposit. List payouts to find the one matching a bank line item, then read its amount, status, and arrival:

cURL
curl "https://api.withflintpay.com/v1/payouts?page_size=20" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Flint-Version: 2026-09-07"

A payout tracks its own lifecycle through arrival, including failures and reversals, so a deposit that never landed is visible as a failed or reversed payout rather than a silent gap. For schedules, destinations, and failed payouts, see Payouts.

Practical guidance#

  • Reconcile in the original currency. Every amount stays in the currency it was collected in, and Flint never blends currencies into one total. Group by currency before summing anything.
  • Use webhooks to build the ledger incrementally. balance_transaction.created fires once per ledger entry and carries the same signed amounts, so you can accumulate as events arrive instead of re-listing. Deduplicate by balance_transaction_id. See Webhook event payloads.
  • Expect settlement lag. Funds move from pending to available on their own schedule, and ACH payments succeed days after confirmation. A payment recorded today may not be in a deposit until later, so reconcile on the ledger's own timestamps rather than assuming same-day settlement.

Next steps#

  • Payouts: when Flint pays you, your payout schedule, and what to do when a payout fails.
  • Processing fees: what Flint charges and when the fee becomes final.
  • Reports: the same ledger as a downloadable CSV, plus order, payment, Flint billing, payout, and tax reports.
  • Flint billing: what you owe Flint, the credit you hold, and how Flint collects.
  • Money & currency: minor units, signed fields, and the amount conventions used here.
  • Money Movement API reference: balances, balance transactions, payouts, and payout destinations.

Was this helpful?