Accounting for Fintech and Payments Companies

At a typical software company, the money that hits the bank account is the company's revenue. At a payments or fintech company, most of the money moving through the bank account is never yours; it belongs to a merchant, a cardholder, or a borrower, and it just passes through. That single fact changes almost every part of the books: the general ledger needs a clean line between funds you're holding for someone else and funds you've actually earned, revenue recognition has to answer "am I the principal or the agent in this transaction" before a number goes on the P&L, and the balance sheet often needs a customer-funds-held liability that has no equivalent in a standard SaaS chart of accounts.

Add reconciliation complexity: a card transaction that happens today doesn't settle into your bank account for one, two, or sometimes several business days, and the amount that lands is net of interchange, network fees, and the processor's own cut, none of which show up as separate line items unless you build a process to break them out. A lending book adds a second layer: outstanding loans, accrued interest, and a reserve for losses that has to be re-estimated every period under a specific accounting standard, not by gut feel. Get any of this wrong and it's rarely one number that's off; it cascades, revenue gets overstated, customer-funds liabilities don't tie to actual holdings, and a regulator or investor doing diligence finds a discrepancy in the first ledger they pull.

None of it is exotic once the right process is built the first time. The rest of this guide breaks the fintech-specific pieces out one at a time: settlement reconciliation, interchange and fee accounting, safeguarding client money, revenue recognition for platforms, lending-book accounting, chart of accounts design, and what regulators expect your books to be able to produce on short notice.

Every card or ACH transaction your platform touches goes through a processor (Stripe, Adyen, Marqeta, a bank partner, or your own acquiring relationship), and the amount that eventually lands in your bank account almost never matches the gross transaction amount your product shows the customer. Between the moment a customer pays and the moment cash settles, the processor nets out its own fees and interchange, and sometimes holds back a rolling reserve against chargeback risk.

The reconciliation that has to happen every period, ideally daily or weekly rather than saved for month-end: pull the processor's settlement report (the raw file, not a dashboard summary) and match it line by line against gross transaction volume recorded in your product or ledger system, fees and interchange deducted, the net amount that actually deposited, and any reserve the processor is holding that hasn't been released yet. A clearing account (sometimes called "processor in transit") sits on the balance sheet between the day a transaction happens and the day cash settles; if that account isn't reconciled to zero, net of legitimate float, every period, small timing differences accumulate into a balance nobody can explain by month twelve.

• Gross transaction volume processed this period, from the product or ledger side, not the bank statement
• Fees, interchange, and network assessments deducted by the processor, broken out by type, not lumped into one number
• Net settlement that actually deposited to the operating bank account
• Reserve held back by the processor against chargeback or fraud risk, tracked as a receivable until released

A monthly close that starts from the bank statement and works backward, instead of starting from the processor's settlement file and working forward, is the single most common source of unreconciled fintech ledgers. Build the process the other way around from day one.

Interchange is the fee a card-issuing bank charges on every card transaction, and it's the single largest cost line for most payments businesses, often larger than payroll in early-stage cases. It's set by the card networks and varies by card type, merchant category, and transaction method, and for large bank issuers, debit interchange is capped under the Federal Reserve's Regulation II. That cap has been adjusted before and can be adjusted again, so confirm the current figure directly on the Federal Reserve's Regulation II page rather than an older source before pricing anything off it.

For accounting purposes, the question isn't just how much you paid, it's where it sits on the P&L. Interchange and network fees that are a direct cost of processing a transaction belong in cost of revenue, not operating expense, the same logic that puts hosting costs inside cost of revenue for a SaaS company. If your platform earns a spread (charging the merchant more than the interchange and network cost you're passing through), that spread is your revenue. Booking the full gross transaction amount as revenue and the full interchange cost as an expense, rather than netting to the spread you actually earn, is one of the fastest ways to overstate both revenue and cost of revenue and confuse anyone reading the P&L trying to understand unit economics.

• Interchange paid to the card-issuing bank, largest single component for most card transactions
• Network assessments paid to the card networks for using their rails
• Processor markup the payment processor's own fee on top of interchange and assessments
• Your platform's take rate what you actually keep, the number that belongs in revenue

Track these four as separate GL accounts, not one blended "payment processing expense" line, so a unit-economics question can be answered by pulling a report instead of reconstructing it from a settlement file.

If your fintech holds customer funds, whether that's a wallet balance, an escrow deposit, funds in transit before disbursement to a seller, or float on a prepaid card program, those funds are a liability owed to the customer, not an asset the business gets to spend, and they should never sit on your P&L as revenue or income at any point.

The accounting mechanics: customer funds typically sit in a segregated bank account, often structured as a "for the benefit of" (FBO) account held at a partner bank on behalf of your customers, kept separate from your own operating cash. On your balance sheet, that shows up as a restricted cash asset on one side and a matching customer-funds-held or funds-payable liability on the other, and the two should always tie to each other, dollar for dollar, at the close of every period. If they don't tie, that's not a rounding error to explain away, it's the first thing an auditor, a bank partner, or a state examiner will flag, because a mismatch usually means either funds went somewhere they shouldn't have or the reconciliation process itself is broken.

Money transmitter licensing, which most US states require to hold and transmit customer funds and which is tracked through NMLS, generally comes with its own permissible-investments or reserve requirement, meaning outstanding customer obligations have to be backed, dollar for dollar, by specific allowed asset types held for that purpose. The exact permissible-investment rules and reserve ratios vary by state and change periodically, so confirm the current requirement with your money transmitter counsel or the relevant state regulator rather than assuming last year's rule still applies. Whether or not your specific structure requires a license (bank-partnership and BaaS models can shift where the licensing obligation sits), the accounting discipline is the same: customer funds get their own segregated bank account, their own balance sheet line, and a reconciliation that happens every single period, not just at year-end.

The single most consequential judgment call in fintech and marketplace accounting is whether your company is the principal or the agent in a transaction, because it determines whether you record the full gross transaction value as revenue, with a matching cost of revenue, or only your net take (fee, commission, or spread) as revenue. Under ASC 606, the test is whether you control the good or service before it transfers to the customer; a company that controls the underlying service is the principal and reports gross, while a company that is only arranging for someone else to provide the service is the agent and reports net.

For a payments platform, this usually means: if you're processing a payment on behalf of a merchant and simply taking a fee, you're almost always the agent, recording only your fee as revenue, not the full transaction amount. A lending platform originating loans it holds on its own balance sheet is generally the principal for the resulting interest income. A marketplace connecting buyers and sellers, where the seller sets the price and bears the risk of the sale, is usually the agent on the transaction value and books only its commission as revenue. Getting this wrong in the growth-optimistic direction, booking gross when you should book net, inflates revenue and cost of revenue by the same amount, which can look impressive on a top-line slide and then become a serious restatement problem the moment an auditor or acquirer's finance team tests it during diligence.

• Principal controls the good or service before transfer, bears inventory, fulfillment, or credit risk, reports gross revenue and a matching cost of revenue
• Agent arranges the transaction for someone else, reports only the net fee or commission as revenue

This determination should be documented in writing, transaction type by transaction type, the first time a new product or revenue stream launches, not reverse-engineered a year later when an investor asks why gross revenue and net revenue tell two very different growth stories.

A fintech that originates or holds loans carries a second, distinct accounting workstream on top of everything else: the loan portfolio needs its own ledger discipline, separate from operating cash and payment processing. At origination, a loan becomes an asset on the balance sheet at its principal amount, net of any origination fees or costs, which typically get deferred and recognized over the life of the loan rather than booked all at once. Interest income accrues over the loan term using the effective interest method, not simply booked as cash is collected, so a loan that's current but hasn't yet had a payment come due can still generate accrued interest income for the period.

The reserve for expected losses is where most fintech lending books get into trouble. Under ASC 326, the Current Expected Credit Loss standard commonly called CECL, a company has to estimate expected credit losses over the full life of the loan portfolio at origination and update that estimate every period, based on historical loss experience, current conditions, and reasonable forecasts, rather than waiting until a loan is actually past due to reserve against it. For a new lending program without years of its own loss history, this usually means leaning on a proxy portfolio, a comparable lender's historical charge-off data, until enough of your own data exists, and documenting that methodology clearly, because a reserve number with no documented basis behind it is one of the first things a lender, auditor, or regulator will challenge.

• Loan principal booked as an asset at origination, net of deferred origination costs
• Accrued interest income recognized over time using the effective interest method
• Loan loss reserve (CECL, ASC 326) a contra-asset reducing the loan book to its expected net realizable value, re-estimated every period

Confirm your specific reserve methodology and the current CECL implementation guidance with a CPA who has actually built one before turning on a lending product, not after the first loss shows up.

A chart of accounts copied from a generic SaaS or services-business template will not hold up for a fintech, because it has no place to put customer-funds liabilities, processor clearing accounts, interchange expense, or loan-related balances, and finance teams end up stuffing all of it into whatever account happens to be open, which makes the books unreadable within two quarters.

A workable structure separates at least these groups, each with its own account range: operating cash (your own money, kept strictly apart from customer funds); customer funds held or funds payable (a liability matched to restricted or FBO cash, never mixed with operating cash); processor clearing or in-transit (a short-lived asset or contra-asset that should net close to zero every period, tracked separately by processor if you use more than one); loan assets and loss reserves (if you lend, kept fully separate from operating assets); interchange, network fees, and processor markup (broken out inside cost of revenue, not blended into one payment-costs line); and platform or take-rate revenue (your actual net revenue, distinct from gross transaction volume, which usually belongs in a memo or KPI schedule rather than the P&L itself if you're an agent under ASC 606).

• Don't: one generic "payment processing" expense account for everything a processor deducts
• Do: separate GL lines for interchange, network assessments, and processor markup
• Don't: customer funds and operating cash in the same bank account or the same GL account family
• Do: a dedicated liability account for funds held, reconciled every period to the restricted cash asset it backs

Build this once, correctly, before transaction volume gets large enough that re-mapping historical data becomes its own project. A chart of accounts that already separates these categories is also the difference between a due-diligence data pull taking an afternoon and taking three weeks.

Finbryn does not file regulatory reports on your behalf, and audits are out of scope for what we do; we prepare audit-ready books and PBC packs, and an independent firm handles the actual audit or exam. But the accounting function still has a direct job here: making sure the underlying ledger can produce, quickly and accurately, whatever a bank partner, state examiner, or auditor asks for.

For a company registered as a money services business, that typically means being ready to support a BSA/AML program with transaction records that tie to actual settlement data, not estimates, since regulators expect to trace a specific transaction from the customer-facing event through to the ledger and back. FinCEN registration for money services businesses runs on a recurring renewal cycle; confirm the current renewal interval and any recent rule changes directly on FinCEN's MSB registration page, since BSA implementing rules do get updated. If you operate under a bank-partnership or BaaS model, your bank partner will run its own periodic reviews of your program and will expect clean, reconciled books as a baseline, not a bonus.

• Trace-ability: every dollar in a regulatory report should tie back to a specific transaction in the ledger, not a rounded estimate
• Segregation evidence: customer-funds reconciliations, dated and retained, ready to hand over on short notice
• Loss reserve documentation: the CECL methodology and its inputs, written down, not reconstructed after the fact
• Audit-ready PBC packages: schedules an independent auditor can work from directly, cutting the audit fee and timeline

The common failure mode isn't fraud, it's books that were close enough for internal management reporting but fall apart the moment an external party needs to trace a number back to its source. Build the reconciliation discipline as if an examiner could ask for it tomorrow, because at some point, one will.

A general month-end close checklist (bank reconciliation, accruals, prepaid amortization) still applies, but a fintech close needs several items layered on top that a standard checklist doesn't cover.

• Reconcile every processor clearing account to zero, net of legitimate float, broken out by processor if there's more than one
• Tie the customer-funds liability to restricted or FBO cash, dollar for dollar, and investigate any variance the same period it appears, not next quarter
• True up interchange, network fee, and processor markup accruals against the actual settlement file, not an estimate carried from last month
• Re-run the loan loss reserve calculation if you carry a lending book, updating for actual charge-offs, new originations, and any change in forecast assumptions
• Confirm the principal-versus-agent revenue treatment hasn't silently drifted as new products or partner arrangements launched during the month
• Review any reserve the processor is holding back against chargebacks and confirm it's still tracked as a receivable, not written off prematurely
• Check any regulatory reserve or permissible-investments requirement tied to money transmitter licensing is still met as of period end

Run this list in the same order every month, with the same person or pod owning each line, so a variance shows up as a flagged exception rather than something discovered by accident three months later when a bank partner or investor asks a question the team can't answer on the spot.

The single most expensive mistake is booking gross transaction volume as revenue when the business is actually an agent under ASC 606. It happens most often when a finance team copies revenue recognition logic from a straightforward SaaS or services business without stopping to ask the principal-versus-agent question transaction type by transaction type, and it inflates both revenue and cost of revenue by the same amount, which usually gets caught during a fundraise or acquisition diligence process, at the worst possible time to discover it.

A second common mistake: mixing customer funds and operating cash in the same bank account, even temporarily, "just to simplify things." It never simplifies anything; it creates a reconciliation nightmare and, depending on your licensing structure, can be a direct violation of money transmitter or safeguarding requirements that a state examiner treats seriously.

A third: treating the loan loss reserve as a set-and-forget number calculated once at origination instead of re-estimated every period under CECL, which understates the reserve the longer a portfolio ages and creates a sudden, large catch-up adjustment later that looks like a crisis when it's really just deferred maintenance on the books.

A fourth, more basic one: closing the books from the bank statement backward instead of the processor settlement file forward, which hides timing differences inside the bank balance instead of surfacing them in a clearing account where they can actually be investigated and resolved.

A payments platform processes $500,000 in gross card transaction volume for its merchants on a given day. The card networks and issuing banks charge $8,750 in interchange and network assessments (a 1.75% blended rate), the underlying processor charges the platform a further $1,000 markup fee, and the processor holds back a $2,500 rolling reserve against chargeback risk before releasing the rest. The platform charges its merchants a flat fee that nets out to $14,500 in gross fee revenue for the day's volume in this example.

Because the platform is the agent for the underlying card transaction (it doesn't control the payment itself, it's arranging for the card network and issuing bank to move the money), it does not book the $500,000 as revenue. It books the transaction as follows: cash and clearing increases by $487,750, which is $500,000 gross minus $8,750 interchange and network fees minus $1,000 processor markup minus $2,500 held reserve. A reserve receivable of $2,500 sits on the balance sheet until the processor releases it. Cost of revenue includes the $9,750 in interchange, network fees, and processor markup. Revenue is the platform's own $14,500 fee, not the $500,000 gross volume. The merchants' $500,000 minus the platform's $14,500 fee, or $485,500, is a liability owed out to the merchants as funds payable, not the platform's revenue or cash to spend freely, and it should hit a segregated funds-held account, reconciled the same day.

This is the difference between a P&L that reads $500,000 in "revenue" with confusing costs underneath, and one that reads $14,500 in actual revenue against $9,750 in direct cost of revenue, a much clearer picture of margin that any investor or lender can actually underwrite.

General bookkeeping and a fintech-fluent finance function are not the same skill set. A team that has never reconciled a processor settlement file, never had to make a principal-versus-agent call, or never built a CECL reserve from scratch will get the mechanics wrong the first several times, and in this industry the first several times usually happen in front of a bank partner, an examiner, or a Series A diligence team.

Signals it's time to bring in fintech-specific accounting support: the monthly close routinely shows an unexplained variance in the processor clearing or customer-funds-held accounts; a bank partner or investor has asked a revenue recognition or reserve-methodology question the internal team couldn't answer on the spot; you're about to launch a lending product and have no documented CECL approach yet; or you're heading into an audit, a bank-partnership renewal, or a fundraise and need books that can survive a line-by-line review of exactly how gross transaction volume becomes reported revenue.

None of this replaces your money transmitter counsel, your bank partner's own compliance review, or an independent auditor. It's the accounting layer underneath all three: the reconciled ledger, the documented revenue policy, and the audit-ready PBC pack that make everyone else's job faster and your own numbers defensible.