Controller's Reference · 2026 Edition

Payments 101:
A Controller's
Field Guide

The definitive accounting and finance reference for payments controllers. Merchant acquiring, card issuing, network economics, and the full close — written for professionals who need to own the numbers, not just understand them.

Join the List
24
Chapters
110+
Glossary Terms
10
SVG Diagrams
ASC
606 · 450 · 815 · 830

Table of Contents

01

Payments Lifecycle

Auth, clearing, settlement. Four-party model. T+0 to T+2 timing. Journal entries.

02

Account Flows & Money Movement

Fee waterfall. Full journal entry lifecycle. GL mapping. $100M portfolio model.

03

Revenue Recognition

ASC 606. Gross vs. net. Principal vs. agent. Journal entries. RevRec checklist.

04

Interchange & Scheme Economics

Visa/MC rate tables. MDR pricing models. Downgrade mechanics. Scheme fee accrual.

05

Reserves & Risk

Rolling, capped, upfront reserves. ASC 450. Journal entries. Release triggers.

06

FX & Cross-Border

ASC 830/815. DCC revenue. Remeasurement entries. FX controls and hedging.

07

Reconciliation & Close

Settlement rec. Scheme billing. Cutoff entries. Close calendar. Break taxonomy.

08

Chargebacks & Disputes

CB lifecycle. Reason code taxonomy. P&L flow-through. Reserve implications.

09

Close Playbook

Variance bridge. Network quarterly billing in arrears. Margin decomposition.

10

Controller KPIs & POS Accounting

Dashboard metrics. Float economics. Terminal sale vs. lease accounting.

11

Issuing Side Accounting

Interchange as revenue. Rewards expense. CECL. Co-brand economics.

12

Revenue Share & Partner Economics

ISO residuals. PayFac splits. Contra vs. expense. Audit risk areas.

13

Volume Definitions & Mix Risk

Auth vs. cleared vs. settled vs. reported vs. eligible — and why it matters.

14

Network Reporting (Visa/MC)

CBS/MCBS billing. Accrual vs. invoice. Quarterly fee true-ups. Assessment logic.

15

FTP & Balance Sheet Mechanics

Settlement float. Merchant payables. Cardholder receivables. CECL. FTP income.

16

End-to-End Master Flow

Auth → Clearing → Settlement → Accruals → Close. All journal entries. $100M model.

■

Controller Tools

Seven controller tools — P&A Classifier, net revenue, scheme fees, reserves, FTP, issuing interchange, ISO waterfall.

17

Fraud Economics & Accounting

Fraud vs. CB taxonomy. Network monitoring program costs. Fraud reserve methodology.

18

Merchant Bankruptcy & Credit Risk

Default timeline. Reserve draw-down. CECL vs. incurred. Clawback. Recovery accounting.

19

Deferred Revenue & Contract Liabilities

Setup fees. SaaS bundles. SSP allocation. Roll-forward close procedure.

20

Stablecoins & Crypto Payments

ASC 350 vs. ASU 2023-08. Stablecoin classification. Instant convert vs. hold.

21

Escheatment 101

Dormancy periods. State priority rules. Breakage-escheat double exposure.

22

AI & Agentic Payments

Autonomous payment agents. Control frameworks. Controller risk model.

23

BNPL Controller Framework

ASC 606 treatment. Receivable position. Contra-revenue. Reserve methodology.

24

Breaking Into Payments Finance

30/60/90 day roadmap. ETA CPP. 10-K case studies. Credibility framework.

GL

Glossary

110+ controller-grade definitions spanning acquiring, accounting, and emerging payments.

Who This Is For
This guide is written for controllers, senior accountants, and finance professionals working in or transitioning into payments — acquiring, issuing, or both. It assumes fluency in core accounting (GAAP, close processes, GL mechanics) and builds domain-specific payments knowledge on top of that foundation. If you're a Big 4 auditor moving into industry, an FP&A professional expanding into technical accounting, or a controller new to the payments space — this is your starting point.
// Audio Overview
Podcast-Style Walkthrough of the Handbook

A simple end-to-end audio overview — how payments actually work, where the money goes, and what controllers need to own to close the books and explain the numbers.

Audio Overview · Deep Dive · ~42 min
Inside the Credit Card
Accounting Machine
A deep dive into the credit card accounting machine — how every tap, swipe, and click translates into journal entries, balance sheet movements, and P&L lines. Covers the full acquiring lifecycle from authorization through close, including interchange economics, revenue recognition, reserves, float, and how to explain the numbers to a CFO.

EDUCATIONAL CONTENT ONLY — This handbook is a general industry reference based on publicly available accounting standards and controller-style analysis. It does not contain confidential, proprietary, or employer-specific information. Accounting treatments and financial statement presentations described herein may vary based on company-specific facts, contract terms, auditor judgments, and applicable GAAP interpretations. Always consult your accounting policy, legal, tax, and compliance teams before relying on specific treatments.

SISTER SITES  ·  controllerpm.com  ·  liquiditycontroller.com  ·  theagenticcontroller.com  ·  Sources & Attestation

Chapter 01

The Payments
Lifecycle

From swipe to settlement — the full authorization, clearing, and settlement sequence, and the four-party model every acquirer controller must own cold.

Every card transaction moves through a defined sequence of phases, each with distinct timing, counterparties, and accounting triggers. As an acquirer controller, your P&L, your settlement liability, and your reconciliation exposure are all governed by where a transaction sits in this lifecycle at month-end. Misunderstanding phase boundaries is the single most common source of controller-level reconciliation errors in payments finance.

The Four-Party Model

The dominant structure in card-based payments is the four-party (open-loop) model, in which the card network sits between the issuing and acquiring sides of the transaction without directly holding funds. This is the Visa and Mastercard architecture. The three-party model (Amex, Discover pre-network deals) collapses the issuer and acquirer roles, producing different economics entirely.

Four-Party Model — Authorization & Settlement Flow
CARDHOLDER + ISSUER Major US Issuers CARD NETWORK Visa / MC Switch & Rules ACQUIRER Acquirer Merchant Services MERCHANT DDA Net of MDR → AUTH REQUEST (T+0) → ← AUTH RESPONSE (Approve/Decline) ← NET SETTLEMENT (T+1/T+2) INTERCHANGE PASS-THROUGH AUTH T+0 CLEARING T+1 SETTLEMENT T+1/T+2

Phase 1: Authorization (T+0)

Authorization is a real-time approval request routed from the merchant's terminal or gateway, through the acquirer, across the card network, to the issuer's authorization system. The issuer verifies funds/credit availability, fraud rules, and account status, returning an approval or decline code — typically within 1–3 seconds.

Controller Note
Authorization creates a hold on the cardholder's account but does not move money. That cash fact does not by itself decide revenue. Under ASC 606 you must first identify the promised service and when control transfers (ASC 606-10-25-23 through 25-30). For a transaction-processing obligation satisfied at clearing, no revenue arises at authorization. But where the contract prices a separate authorization or gateway service — a per-auth fee, a decline-handling fee, a standalone risk-screening service — that service can be satisfied and earn revenue even if the purchase never clears. Do not read "no money moved" as "no performance obligation satisfied."

Uncaptured auths age on your open items report and inflate the authorization-to-clearing gap. Clean them weekly — they clutter reconciliation and mask real breaks. Authorization validity windows vary by network, region, MCC and transaction type and are set by the applicable network rules, not by a single universal deadline; see the auth-lifecycle table below before quoting any specific number.

Phase 2: Clearing (T+1)

Clearing is the process by which the merchant submits its final batch of transaction data to the network for financial settlement. In card-present environments, clearing may occur same-day or next-day as part of end-of-day batch capture. In CNP/e-commerce, clearing typically occurs at shipment or service delivery. Clearing is the event that triggers interchange qualification.

The clearing message includes the final transaction amount (which may differ from the authorized amount — notably in lodging, restaurant, and car rental environments where tips and final charges are added post-auth), merchant category code, and acquirer processing information. The network uses this data to calculate interchange and net settle between issuers and acquirers.

Auth vs. Clearing Delta
Where the cleared amount exceeds the authorized amount beyond the applicable tolerance, the transaction may lose its authorization protection, downgrade, or become subject to dispute rights — outcomes that differ by network and scenario. Tolerances are set per network, region, MCC and transaction type (estimated vs. incremental vs. final authorization); a figure such as 15–20% is an illustrative order of magnitude, not a rule to cite. Confirm the current percentage against the applicable network rule before using it in a control threshold. This is a common operational risk in T&E merchants and requires acquirer-side monitoring.
Four Deadlines Controllers Routinely Conflate
A single "auths expire in 7 days" rule of thumb collapses four distinct concepts that have different owners, different rule sources and different P&L consequences. Separate them in your documentation:
ConceptWhat it governsSet byConsequence if breached
Authorization validityHow long an approval remains usable for clearingNetwork rules, by MCC / transaction type / regionLoss of auth protection; possible downgrade or dispute exposure
Cardholder hold releaseWhen the issuer drops the hold on available credit/fundsIssuer practice within network rulesCardholder complaint; no acquirer GL impact
Timely presentmentDeadline to submit clearing after the transaction dateNetwork processing rulesInterchange downgrade; late-presentment fees
Dispute / chargeback rightsWindows for the issuer to raise and the acquirer to representNetwork dispute rules; Reg E / Reg Z where applicableLost representment rights; write-off
Control: maintain a dated internal matrix of these four windows by network, region and MCC, sourced to the current rulebook version, and re-verify it each time a network publishes a rules update. Do not hard-code a single number into your open-auth aging logic.
Primary sources: Visa Core Rules and Visa Product and Service Rules (authorization and processing sections); Mastercard Transaction Processing Rules.

Phase 3: Settlement (T+1 / T+2)

Settlement is the actual movement of funds between the issuer and acquirer, netted by the card network. Visa and Mastercard operate settlement through Visa Settlement Service (VSS) and Single Message System/Dual Message System respectively. Net settlement positions are calculated across all transactions cleared on a given business day, with the network acting as a central counterparty.

T+0 Settlement

Same-day settlement, typically reserved for large acquirers with direct settlement relationships. Requires intraday liquidity and specialized network connectivity.

T+1 / T+2 Settlement

Standard settlement window. Most merchant credit card transactions settle T+1 or T+2 from the clearing date. Debit networks often settle same-day or T+1.

Gross Settlement Position

Issuer bank owes acquirer bank: gross transaction amount minus interchange fee. The network calculates and nets this daily across millions of transactions.

Merchant Funding

Acquirer funds the merchant DDA, typically net of MDR (merchant discount rate), on T+1 or T+2 from clearing. Reserve holds, chargebacks, and adjustments reduce the funded amount.

Timing Summary

PhaseTimingFinancial Event?Controller Trigger
AuthorizationT+0, real-timeNoNo GL entry for the processing obligation; open auth tracking. A separately priced auth/gateway service is recognized on its own terms.
ClearingT+1 (batch)YesInterchange qualification; revenue recognized for a processing obligation satisfied at clearing; receivable and merchant payable raised
Network SettlementT+1 or T+2Cash onlyCash received; relieves the settlement receivable. No revenue entry — revenue was recognized at clearing
Merchant FundingT+1 to T+3Cash onlyRelieves merchant payable; net of reserves and CBs. No revenue entry
Why This Table Says Clearing, Not Settlement
The timing above reflects one documented policy conclusion for a specific fact pattern: a transaction-processing obligation whose control transfers when the transaction is cleared and the merchant's claim to funds becomes unconditional. It is not a universal GAAP rule. Reach it the same way every time:

1. Identify each promised service in the merchant contract (processing, gateway, authorization, risk screening, terminal, chargeback handling).
2. Determine whether each is satisfied over time under ASC 606-10-25-27 or at a point in time.
3. For point-in-time obligations, apply the control indicators in ASC 606-10-25-30.
4. Document the conclusion per obligation and apply it consistently in the journals, the close checklist and the systems configuration.

A dual-message environment (separate authorization and clearing messages) and a single-message environment (authorization and clearing combined) must be mapped separately, because the operational event that evidences control transfer differs. Neither "cash has moved" nor "the network sent message type X" is the test.
ASC 606-10-25-23 through 25-30. Single- vs. dual-message processing: Mastercard Transaction Processing Rules.

Controller Checklist — Payments Lifecycle

Monthly Close Checklist · Lifecycle Controls
Thresholds below are illustrative starting points. Calibrate each to your own portfolio history and document the basis; they are not network requirements or benchmarks.
□ Confirm auth-to-clear conversion rate against your calibrated tolerance — flag exceptions for investigation
□ Verify no clearing files unprocessed beyond the applicable timely-presentment window (downgrade risk)
□ Confirm T+1/T+2 settlement receivable clears within 3 business days
□ Auth count × average ticket ties to clearing volume within tolerance
□ Any auth past its applicable validity window and not captured → clear from open auth log (memo only; no GL write-off, since no asset was recognized)
□ Confirm cutoff: all cleared transactions dated in period are booked in period
□ Settlement file transaction count reconciles to processing system count
□ Any net settlement position break >$10K → escalate same day
Failure Scenario — Auth Without Capture (Lost Revenue)
What happens: Hotel pre-auths $500 at check-in. Guest checks out and the PMS system fails to send the capture. The authorization lapses under the applicable network validity window. No clearing, no settlement, no revenue — but the cardholder's available credit was reduced in the meantime.
P&L impact — the $500 is not the loss. The $500 is the cardholder's purchase principal, which the acquirer never owned. What is lost is the fee on that volume: $500 × 1.75% = $8.75 of gross MDR. Against that, the avoided interchange ($7.00) and scheme fees ($0.65) are also never incurred, so the true margin forgone is $1.10 (the 22-bp net spread on $500). Gross MDR is the right measure for a revenue-leakage KPI; net spread is the right measure for margin impact. State which one you are quoting.
At portfolio scale — state the period. If 1% of annual GTV of $100M fails capture, $1M of volume is lost, and gross MDR leakage is $1M × 1.75% = $17,500 per year (net spread: $2,200). If that $100M is monthly volume, the same 1% failure rate produces $210,000 of annual gross MDR leakage (net spread: $26,400). A leakage figure without a stated period and a stated rate is not reviewable.
Controller control: Monitor auth-to-capture lag by MCC weekly. Lodging (7011) and car rental (7512) carry the highest structural exposure because of the pre-auth/final-charge gap. Set capture-rate floors from your own portfolio history rather than a generic benchmark, and route any MCC breaching its floor to a merchant operations review.
🔍 Controller Lens — Payments Lifecycle
WHAT CREATES THE ASSET?Clearing creates the Settlement Receivable. Auth creates no asset — only a cardholder hold.
SOURCE OF TRUTHNetwork clearing and settlement files. Internal processing system is secondary. Bank statement confirms cash receipt.
TIMINGRevenue = clearing date. Cash = settlement date (T+1/T+2). Never confuse the two for period cutoff.
KEY RISKAuth-to-clear gap. Late presentments. Downgrade from missing data elements at clearing. Each has different P&L impact.

Journal Entries — Payments Lifecycle

Complete Lifecycle Journal — Single $100 Transaction
T+0 Authorization — No Entry
Auth request sent. Issuer approves. Cardholder hold placed. No money moves.
Acquirer open auth log: +1 item · No GL impact

T+1 Clearing — Revenue Recognition
Assumption: both interchange and scheme fees are withheld by the network inside the same net settlement.
Dr Settlement Receivable         $98.47  ($100.00 − IC $1.40 − scheme $0.13)
Dr Interchange Expense            $1.40
Dr Scheme Fee Expense             $0.13
  Cr Merchant Payable                $98.25  ($100.00 − MDR $1.75)
  Cr MDR Fee Revenue                $1.75
Total Dr = $100.00 · Total Cr = $100.00 ✓
Acquirer margin captured: $1.75 − $1.40 − $0.13 = $0.22 (22 bps)

T+2 Settlement — Cash Receipt
Dr Cash — Settlement Account    $98.47
  Cr Settlement Receivable          $98.47

T+2 Funding — Reserve Withheld
Dr Merchant Payable                $98.25
  Cr Merchant Reserve Liability     $10.00  (10% of $100 GTV — merchant's funds, not the acquirer's)
  Cr Cash / ACH Payable              $88.25  (net funded to merchant DDA)

Cash proof: received $98.47, paid out $88.25, reserve held $10.00 → retained $0.22 = the recognized spread ✓
The $0.22 Spread Is Where Most Errors Hide
The receivable and the merchant payable are not the same number, and setting them equal is the single most common error in acquirer lifecycle journals. The acquirer collects $98.47 from the network but owes the merchant only $98.25. The $0.22 difference is the margin — so a journal that debits and credits $98.25 has silently eliminated the entire economics of the business while still appearing to balance.

If scheme fees are billed separately rather than withheld in settlement, the same transaction books differently: debit Settlement Receivable $98.60 ($100.00 − IC $1.40 only), debit Scheme Fee Expense $0.13, credit Merchant Payable $98.25, credit MDR Revenue $1.75, and credit Scheme Fee Payable $0.13 — discharged later when the network invoices. Pick one model per fee category and hold it consistently through settlement; do not deduct a fee from the receivable and carry a payable for the same fee. See Chapter 2 for the portfolio-level version of this same trap.
ASC 606-10-32-2 (transaction price) and 606-10-45-4; ASC 210-20-45-1 (offsetting).
ISO 8583 Message Types — Controller Reference
0100 → Authorization Request     (acquirer to network)
0110 → Authorization Response   (network/issuer to acquirer) — Approve or Decline
0200 → Financial Transaction Request  (single-message: authorizes and clears)
0210 → Financial Transaction Response
0400 → Reversal Request          (void before clearing)
0420 → Reversal Advice            (void confirmed — release any auth hold)

Dual-message: clearing does not arrive as an 0200 at all. It comes
through the separate batch clearing stream (Visa BASE II / TC records;
Mastercard IPM). The 0100/0110 pair authorizes; the clearing file clears.
Single-message: the 0200/0210 pair does both at once — common in
PIN debit. Map your own environment before wiring any accounting trigger.
Message Type Is Not a GAAP Test
It is tempting to write the policy as "0200 is the accounting event, 0100 is not." Resist it. A message type is operational evidence that a service was performed; it is not the standard. Two reasons this matters in practice:

1. It breaks across environments. If your policy names 0200 as the trigger, it is silently wrong for every dual-message flow in your portfolio, where clearing never produces an 0200. The accounting conclusion has to be expressed in terms of the promised service and the transfer of control, then mapped to whatever message or file evidences it on each rail.
2. It misstates separately priced services. A per-authorization fee, a decline-handling fee or a standalone risk-screening service can be fully satisfied at authorization. Recognizing revenue for those at 0100 is not premature — it is correct, because that is when the acquirer performed what it promised.

Write the policy as: "Revenue for the transaction-processing obligation is recognized when control of the processing service transfers, evidenced in our dual-message environments by acceptance of the transaction in the network clearing file and in our single-message environments by the 0210 approved financial response." That statement survives a rails change and an auditor's follow-up question. "0200 is the trigger" survives neither.
ASC 606-10-25-23 through 25-30.

Alternative Rails — Real-Time Payments (FedNow / RTP)

Not all payments run on card rails. The FedNow Service (launched July 2023) and The Clearing House RTP network operate instant payment rails that settle in seconds — not days. For controllers at acquirers or merchants accepting bank-to-bank payments, these rails have fundamentally different timing, cost, and accounting profiles than Visa/MC.

AttributeCard Rails (Visa/MC)FedNow / RTPACH
Settlement timingT+1 to T+2Instant (seconds)T+1 to T+3 (same-day ACH available)
InterchangeYes — 1.40% avgNoneNone (except debit card ACH)
Dispute / recall rightYes — network dispute rulesNo network chargeback mechanism. Recall is a request the receiving bank may decline; the payer's remedy is contractual or legal, not automatic reversalReturn rights vary by return reason and account type — see the return-window note below
Revenue recognition triggerWhen control of the processing service transfers (clearing, in this handbook's baseline fact pattern)When the fee-earning service is performed — typically on confirmed transmission. Instant settlement is evidence, not the testWhen the fee-earning service is performed. Not automatically the funds-credited date
Settlement receivableT+1/T+2 open itemNo settlement float on the principal if the processor never holds it. A fee receivable still arises whenever fees are billed rather than withheld1–3 day receivable during ACH float, plus any fee receivable
Loss exposure requiring an allowanceYes — CB exposure, plus merchant credit riskReduced, not eliminated. No CB right removes one channel; fraud, erroneous-payment claims, merchant credit risk and contractual indemnities remainReturn risk, unauthorized-debit claims, and merchant credit risk
Acquirer cost modelMDR = IC + scheme + marginFlat fee per transaction ($0.01–$0.10 typical)Flat fee per item ($0.02–$0.30)
Settlement Finality Is Not the Same as "No Loss Exposure"
The row above deliberately stops short of the common shortcut "instant and irrevocable, therefore no receivable and no allowance." Three separate questions have to be answered independently:

Is settlement final? On RTP and FedNow, yes — a credit transfer is irrevocable once accepted. That governs whether the funds can be pulled back through the rail.
Does anyone still have a claim? Often yes, through a different door. A payer defrauded into sending a push payment has legal and contractual remedies even though the rail offers no chargeback. A receiving institution may honor a recall request but is not obliged to. Finality closes the rail, not the courthouse.
Who owes you, and for what? The principal and the fee are different assets with different obligors. Even where the processor never touches the principal, a fee billed in arrears is a receivable from the merchant and carries that merchant's credit risk — which is exactly the exposure CECL addresses.

On ACH return windows: "two business days" describes only the administrative return reasons — insufficient funds, account closed, no account. It is not the outer limit. Unauthorized consumer debits carry a materially longer return window, and a consumer's error-resolution rights under Regulation E run from the periodic statement on their own timetable, with defined investigation and provisional-credit periods that differ for new accounts, POS and foreign transactions. Build your exposure model from the return-reason-specific windows in the current Nacha rules plus the applicable Regulation E periods — never from a single number.
ASC 606-10-25-23; ASC 326-20-15-2 (CECL scope); ASC 450-20-25-2. Consumer error-resolution periods: CFPB Regulation E §1005.11.
FedNow / RTP Journal Entry — $10,000 Merchant Payment
Model A — processor receives the funds and forwards them
The processor takes the $10,000 into its own settlement account, then pays the merchant net.

Dr Cash — Settlement Account         $10,000.00
  Cr Merchant Payable                   $9,997.00
  Cr RTP Platform Revenue               $3.00  (fee charged to merchant)
Dr = $10,000.00 · Cr = $10,000.00 ✓

The network's own per-transaction cost is a separate entry — it is the processor's
expense, not a deduction from the merchant's money:

Dr RTP Processing Fee Expense      $0.05
  Cr Accounts Payable — Network      $0.05
Dr = $0.05 · Cr = $0.05 ✓
Margin on the transaction: $3.00 − $0.05 = $2.95

Model B — funds settle directly to the merchant
The processor never holds the principal, so the $10,000 never touches its books.

Dr Fee Receivable — Merchant          $3.00
  Cr RTP Platform Revenue               $3.00
Dr RTP Processing Fee Expense      $0.05
  Cr Accounts Payable — Network      $0.05

Pick the model that matches your actual funds flow. The error to avoid is
describing Model B in the narrative ("funds arrive instantly in the merchant's
account") while booking Model A's cash debit — that records cash the entity
never received.
What Actually Changes Versus Card
The genuine difference is settlement float on the principal, not the existence of receivables as such. Under Model B the processor has no principal float to invest and no settlement receivable on the principal — so the float/FTP contribution modeled in Chapter 15 does not arise. Under Model A it briefly does, at whatever the actual hold period is. In both models a fee billed in arrears is still a receivable, still ages, and still requires a credit-loss allowance. "No float" and "no receivables" are different statements, and only the first is reliably true of instant rails.
Controller Note — RTP Changes Your Reserve Model
If your platform shifts volume from card to RTP/FedNow, chargeback exposure drops because the rail provides no chargeback mechanism — but your risk does not simply disappear, it relocates. Push-payment fraud lands on the payer rather than being absorbed by a dispute network, which changes who complains to you and through what channel: contractual indemnity, legal claim, or reputational escalation rather than a network dispute case.

Do not carry that across as "no reserve on RTP volume." Reserve and allowance requirements are driven by the specific exposures you retain, which must be assessed rail by rail: merchant credit risk on fees billed in arrears, erroneous-payment and fraud claims, refund obligations you are contractually on the hook for, and any indemnities in your platform agreements. A chargeback-derived reserve percentage is the wrong input for RTP volume; zero is usually the wrong answer. Model the retained exposures directly, document why each card-based driver does or does not carry over, and distinguish rail types explicitly in your reserve methodology. Auditors will ask.
Chapter 02

Account Flows &
Money Movement

The fee waterfall from gross transaction value to merchant net — and how every basis point flows through the acquirer P&L.

Money movement mechanics sit underneath every revenue recognition call, reconciliation procedure, and margin analysis a payments controller runs. The economics of a single transaction involve four distinct fee layers, multiple counterparties, and netting arrangements that can obscure gross-to-net relationships if not carefully mapped. This section traces funds from the cardholder's bank to the merchant's DDA and maps every deduction.

The Fee Waterfall

Transaction Fee Waterfall — $100 Transaction Example
GROSS TRANSACTION VALUE (GTV) $100.00 Face value of transaction cleared to network LESS: INTERCHANGE FEE — paid by acquirer TO issuer via network − $1.65 1.65% all-in blended cost (item fee included) · largest single cost line LESS: SCHEME / ASSESSMENT FEES — paid by acquirer TO network − $0.14 Blended illustrative rate · per-network components differ — see Ch. 4 NET SETTLEMENT RECEIVED BY ACQUIRER from network $98.21 $100.00 − $1.65 − $0.14 = $98.21 · cash received from Visa/MC settlement LESS: MDR BILLED TO MERCHANT — acquirer charges merchant for processing $2.30 2.30% blended rate · withheld from merchant funding · acquirer's gross revenue ACQUIRER NET MARGIN = MDR − Interchange − Scheme Fees $0.51 $2.30 − $1.65 − $0.14 = $0.51 · 51 bps on $100 · ~22% gross margin on MDR MERCHANT DDA FUNDING = GTV − MDR $97.70 $100.00 − $2.30 MDR = $97.70 · further reduced by reserves, chargebacks, adjustments
■ COST TO ACQUIRER: $1.79 (interchange + scheme)
■ ACQUIRER MARGIN: $0.51 (51 bps)
■ MERCHANT NETS: $97.70 (97.7% of GTV)

Acquirer Economics Decomposed

The acquirer's net revenue — sometimes called the "acquirer take rate" — is the MDR charged to the merchant minus interchange passed to the issuer and scheme fees paid to the network. This spread is the core economic unit of merchant acquiring. Spreads vary enormously by segment — thin on large retail, materially wider on SMB and specialty — which is why this handbook runs two named scenarios (22 bps and 51 bps per $100M) rather than quoting a single industry figure. Any specific range you use should come from your own portfolio data or from dated public filings, not from a rule of thumb.

Acquirer Net Revenue Formula
Acquirer Net Revenue = MDR Billed to Merchant
    − Interchange Cost (paid to Issuer)
    − Scheme / Assessment Fees (paid to Network)
    − Processing & Infrastructure Cost
    = Acquirer Margin (net basis points)

Funding Chain: From Issuer Bank to Merchant DDA

The mechanics of the actual cash movement are important for GL mapping. The card network acts as the settlement agent, maintaining net positions across all members. Each business day, the network calculates multilateral net settlement positions across all acquirers and issuers on the system. The net settlement amount is then moved via the settlement bank (typically a Fed member institution) to each participant's settlement account.

Controller Risk Flag
Merchant DDAs funded via ACH carry a 1–2 business day exposure window. If a merchant goes insolvent after funding but before the return window closes, the acquirer bears the risk of ACH returns or chargebacks funded against the departed merchant. This is the fundamental credit exposure in merchant acquiring and drives reserve policy.

Full Journal Entry Lifecycle — $100M Monthly Portfolio

The following walkthrough traces a single month's $100M portfolio through every accounting event from authorization to funded merchant DDA. This is the journal entry sequence a controller must own cold. This chapter runs on Scenario B, the bundled/SMB pricing set defined below — richer economics than the large-merchant baseline used in Chapters 1, 3 and 16, and chosen here because a 51-bp spread makes each waterfall step legible.

Scenario B — Bundled / SMB Pricing (used in Chapters 2 and 4)
GTV: $100,000,000 · MDR (2.30%): $2,300,000 revenue · Interchange cost (1.65%): $1,650,000 · Scheme fees (0.14%): $140,000 · Acquirer net margin: $510,000 (51 bps) · Avg ticket: $65 · Transactions: ~1.54M/month
Two Named Scenarios — Read the Label Before Reusing a Number
This handbook uses two internally consistent portfolio scenarios. They are both realistic; they describe different books of business. Pulling a figure from one into a journal built on the other is the fastest way to produce an entry that looks reasonable and does not balance.
Per $100M GTVScenario A — BaselineScenario B — Bundled / SMB
ProfileLarge-merchant, interchange-plusSmall/mid-market, bundled rate
MDR1.75% = $1,750,0002.30% = $2,300,000
Interchange1.40% = $1,400,0001.65% = $1,650,000
Scheme fees0.13% = $130,0000.14% = $140,000
Merchant payable$98,250,000$97,700,000
Net spread$220,000 · 22 bps$510,000 · 51 bps
Used inCh. 1, 3, 16Ch. 2, 4
Neither is "the" industry number. A bundled SMB book earning 22 bps would be underpriced; a large-merchant IC++ book earning 51 bps would be uncompetitive. The spread you should expect is a function of the segment, and any figure quoted without its segment is not reviewable.
Step 1 — Authorization (T+0) · No GL Entry
Authorization creates a cardholder hold. No funds move. No journal entry.
Memo entry only: Open Authorization Log · $100,000,000 face value · pending clearance
Step 2 — Clearing (T+1) · Revenue Accrual
Model: both interchange and scheme fees are withheld by the network inside net settlement.
No fee payable is created — the fees are already gone from the receivable.


Dr Settlement Receivable              $98,210,000
Dr Interchange Expense                $1,650,000
Dr Scheme Fee Expense                 $140,000
  Cr Merchant Payable                     $97,700,000
  Cr MDR Fee Revenue                     $2,300,000

Debits = $100,000,000 · Credits = $100,000,000 ✓
Settlement receivable = net due from network (GTV − IC − Scheme)
Merchant payable = GTV − MDR = $100M − $2.30M = $97,700,000
Step 3 — Settlement (T+1/T+2) · Cash Receipt
Dr Cash / Settlement Account          $98,210,000
  Cr Settlement Receivable               $98,210,000

Cash received from Visa/MC net settlement. Receivable clears.
Note: Cash received ($98.21M) > merchant payable ($97.70M) by $510K = acquirer margin.
Step 4 — Reserve Holdback (on funding)
Dr Merchant Payable                    $977,000
  Cr Merchant Reserve Liability          $977,000

Example: 1% rolling reserve on $97.7M merchant payable = $977K withheld
Step 5 — Merchant DDA Funding
Dr Merchant Payable                    $96,723,000
  Cr Cash / ACH Payable                  $96,723,000

Net: $97,700,000 payable − $977,000 reserve hold = $96,723,000 funded to merchant DDAs
Step 6 — Scheme Fees · No Further Cash Entry Under This Model
No entry. The $140,000 was withheld by the network in Step 2 and is
already out of the receivable. There is no scheme fee payable, so there is
nothing left to pay.

Cash proof for the month:
  Received from network             $98,210,000
  Less funded to merchant DDAs    ($96,723,000)
  Less reserve held (liability)        ($977,000)
  Retained                             $510,000 = recognized margin ✓
The Double-Count Trap — Deduct It Or Owe It, Never Both
A fee can be netted out of your settlement receivable, or it can sit in a payable and be paid later. It cannot do both. An entry that deducts $140,000 from the receivable at clearing and later debits a $140,000 scheme fee payable relieves a liability that was never recorded — leaving the payable account permanently negative and overstating cash outflow by the full amount. At portfolio scale this reconciles to nothing and surfaces as an unexplained settlement break.

The separate-billing model, done correctly. In practice interchange is almost always netted in daily settlement while scheme and assessment fees are frequently invoiced on a monthly billing cycle. If that matches your arrangement, Step 2 changes:
Dr Settlement Receivable              $98,350,000  ($100M − IC only)
Dr Interchange Expense                $1,650,000
Dr Scheme Fee Expense                 $140,000
  Cr Merchant Payable                     $97,700,000
  Cr MDR Fee Revenue                     $2,300,000
  Cr Scheme Fee Payable                   $140,000
Dr = $100,140,000 · Cr = $100,140,000 ✓
Step 3 cash receipt becomes $98,350,000, and then Step 6's payment of the $140,000 payable is correct. Cash proof still lands on $510,000: $98,350,000 − $96,723,000 − $977,000 − $140,000.

Control: maintain a fee-category inventory that tags every fee as netted or invoiced, reconcile it to the settlement file and the monthly network invoice, and confirm no category appears in both populations. The categories are not uniform across networks or regions, so this is a mapping exercise, not a single policy election.
ASC 210-20-45-1 (offsetting). Settlement and fee-collection mechanics: Visa Core Rules.
Close Risk — Revenue ≠ Cash
The most common month-end controller error in acquiring: recognizing revenue at clearing (Step 2) but not receiving the cash until T+2 (Step 3). At month-end cutoff, transactions cleared on the last 1–2 business days will have revenue recognized but cash not yet received. The settlement receivable balance on the balance sheet must be validated against the open settlement file — if the receivable has no matching cash receipt within 3 business days, investigate immediately. This is the #1 source of unsupported balance sheet items in acquiring close.

GL Mapping Framework

Entry TypeDebitCreditTiming
Settlement ReceiptSettlement Cash / ReceivableMerchant PayableT+1/T+2
MDR RevenueMerchant PayableFee RevenueAt clearing/settlement
Interchange CostInterchange ExpenseSettlement CashAt settlement
Scheme FeesScheme Fee ExpenseSettlement Cash / APScheme billing cycle
Merchant FundingMerchant PayableCash / ACH PayableFunding date
Reserve HoldMerchant PayableReserve LiabilityPer reserve agreement
🔍 Controller Lens — Account Flows & Money Movement
WHAT CREATES THE ASSET?Net settlement from network creates Settlement Receivable. MDR × GTV drives revenue recognition simultaneously.
SOURCE OF TRUTHNetwork settlement file for cash amounts. MPA (Merchant Processing Agreement) for MDR rate. Internal processing system for transaction count.
TIMINGMerchant Payable = GTV − MDR. Created at clearing. Extinguished at funding. Reserve hold = subset of payable transferred to Reserve Liability.
KEY RISKSettlement receivable exceeds merchant payable by acquirer margin. Any mismatch signals either IC cost variance or MDR billing error. Reconcile daily.
Failure Scenario — Net Settlement Mismatch
What happens: Network sends $98,470,000 net settlement. Controller reconciles merchant payable at $98,250,000. The $220,000 gap equals the acquirer margin — exactly right. But this month the gap is only $185,000. That $35,000 discrepancy is unexplained.

Root causes to investigate in order: (1) Interchange cost higher than accrued — card mix shifted to rewards. (2) Scheme fee billing timing — a fee hit that wasn't in the accrual model. (3) Merchant MDR billing error — a rate applied incorrectly. (4) Chargeback net settlement deduction — CB filed against the acquirer that reduced the network payment. Each has a different fix and a different GL entry.

Control: Calculate expected net settlement from first principles every day: GTV × (1 − IC% − scheme%) = expected receipt. Variance >$10K vs. actual = investigate before 5pm.

Controller Checklist — Account Flows & Money Movement

Daily / Monthly Close Controls
□ Net settlement received = GTV × (1 − IC% − scheme%) within $10K tolerance
□ Merchant payable = GTV × (1 − MDR%) — supported by merchant sub-ledger
□ Reserve withheld this period reconciles to reserve sub-ledger movement
□ MDR revenue = GTV × MDR rate — tied to processing system clearing file
□ Interchange expense = GTV × blended IC rate — tied to network settlement file
□ Net margin = MDR − IC − Scheme = 51 bps on $100M = $510,000 (Scenario B) — verify monthly
□ Any line item where GL ≠ sub-ledger requires same-day investigation
□ Merchant payable balance at month-end = unfunded amounts only (not fully funded merchants)
Chapter 03

Revenue Recognition
(Controller View)

ASC 606 applied to merchant acquiring: gross vs. net, principal vs. agent, performance obligations, and the transaction-level judgments that matter at month-end.

ASC 606 reorganized how acquirer controllers think about revenue. The five-step model is familiar, but its application to payments — where the acquirer is simultaneously a processor, a lender (via float), a risk-taker, and a distributor of scheme economics — creates layered judgment calls that the standard itself leaves only partially resolved. The following covers each step as it applies to acquiring.

The ASC 606 Five-Step Model Applied to Acquiring

Step 1 — Identify the Contract

The Merchant Processing Agreement (MPA). Key attributes: pricing schedule (interchange++ vs. blended), volume commitments, term, termination provisions. Identify relevant riders (e.g., gateway addenda, international processing schedules).

Step 2 — Identify Performance Obligations

Typically: transaction processing services (each transaction is a distinct service), value-added services (fraud tools, reporting, gateway), and potentially stand-ready obligations (chargeback management, dispute services). Bundling analysis required.

Step 3 — Determine Transaction Price

Complex in acquiring. MDR may be variable (interchange-plus structures make acquirer take variable). Scheme fee pass-throughs must be evaluated for inclusion. Constrain variable consideration to the amount not likely to be reversed under the constraint guidance.

Step 4 — Allocate to Obligations

If bundled services exist, allocate based on standalone selling prices (SSPs). Gateway fees, fraud screening, and reporting are often separately priced, simplifying allocation. Challenge arises with all-in blended MDR structures.

Step 5 — Recognize Revenue

Transaction processing: recognize when control of the processing service transfers. In this handbook's baseline fact pattern that is clearing — the point the merchant's claim to funds becomes unconditional — not cash settlement. Stand-ready obligations (chargeback representation, dispute management): recognize over the service period.

Timing Principle

Control is defined in ASC 606-10-25-25: the ability to direct the use of, and obtain substantially all the remaining benefits from, the asset. 25-27 sets the three over-time criteria; 25-30 lists the point-in-time indicators. Cite the one you are actually applying — 25-27 is not the definition of control, and receipt of cash is an indicator, never the test.

The Core Judgment: Gross vs. Net (Principal vs. Agent)

This is the highest-stakes revenue recognition question in acquiring. The principal vs. agent determination drives whether revenue is reported as gross MDR billed to the merchant or net of interchange and scheme fees. The difference is material — on Scenario A's 22 bps net against 175 bps of gross MDR, a gross presentation reports roughly 8× the revenue of a net presentation with identical economics and identical cash. This is a critical disclosure issue for public acquirers and the most consequential accounting judgment call in the business.

The Principal vs. Agent Test — ASC 606-10-55-36 through 55-39A
An entity is a principal if it controls the specified good or service before it is transferred to the customer; an agent arranges for another party to provide it. The analysis is performed per specified service, not once for the contract.

The indicators in ASC 606-10-55-39 support — but do not replace — that control conclusion:
(a) the entity is primarily responsible for fulfilling the promise;
(b) the entity has inventory risk before or after transfer;
(c) the entity has discretion in establishing the price.

Credit risk is not on that list. ASU 2016-08 removed the credit-risk indicator precisely because bearing exposure to a counterparty's non-payment says nothing about whether you controlled the service. An acquirer that bears merchant credit risk may well be a principal — but it must get there through control, not by pointing at the risk. Citing credit risk as a principal indicator is the most common error in acquirer gross/net memos and the first thing a reviewer will strike.
ASC 606-10-55-36 through 55-39A; FASB ASU 2016-08.

Acquiring Revenue: The Gross vs. Net Analysis

The key question is whether the acquirer controls the specified service delivered to the merchant, or merely arranges for the network and issuer to provide it. Direct network membership and proprietary processing infrastructure are relevant because they speak to who directs and is responsible for the service. Assumption of credit risk is not support for a principal conclusion, whatever its commercial significance.

How to Read the Table Below
The presentations shown are common outcomes for typical fact patterns, not a policy menu and not defaults you may adopt by analogy. Gross and net are the results of a control conclusion reached service by service on your own contracts. Two acquirers with different agreements can correctly reach opposite answers on the same revenue line, and the same acquirer can reach different answers across merchant segments. Use this table to see what drives the analysis — then perform it on your facts and document it.
Revenue StreamTypical PresentationRationaleController Risk
MDR / Processing FeesGrossAcquirer directs how the processing service is performed and is primarily responsible to the merchant for it; sets price independentlyControl conclusion must be documented per service. Do not cite credit risk as support
Interchange Pass-Through (I++)NetWhere the acquirer does not control a separately specified service and has no pricing discretion over the network-set rateA pass-through pricing formula does not by itself prove agency — test control of the specified service
Scheme Fee Pass-ThroughNetNetwork fees passed at cost with no acquirer discretionA mark-up changes the amount, not automatically the conclusion. Re-test control; do not assume mark-up = principal
Gateway FeesGrossAcquirer owns and directs the gateway service; SSP is observableAllocation analysis needed if bundled with MDR
Chargeback FeesGrossAdministrative service the acquirer performs and pricesDistinguish from CB reserve (liability, not revenue)
FX / DCC RevenueGrossWhere the acquirer controls the currency-conversion service provided to the cardholder/merchantEarning a spread is not the test. ASC 830 interaction; carve DCC margin from FX translation

Performance Obligations and Contract Modifications

One of the more operationally challenging areas in acquirer revenue recognition is identifying whether a merchant contract re-pricing, volume tier reset, or product bundle change constitutes a contract modification under ASC 606-10-25-10. A modification that adds distinct services at a standalone selling price is accounted for as a separate contract. A modification that changes the scope or price for existing services requires judgment on whether to account for it prospectively or via a cumulative catch-up.

Practical Example
A large retail merchant renegotiates their MDR downward mid-year in exchange for a volume commitment extension. If the new pricing applies prospectively and does not modify the nature of services being delivered, this is typically accounted for as a contract modification with prospective effect. The reduced MDR is applied from the effective date; no catch-up is required unless over-billed periods exist.

Contract Costs (ASC 340-40)

Three different things get swept together under "contract costs," and they follow different rules. Separate them before anything is capitalized.

CategoryExamplesTreatment
Incremental costs of obtaining
ASC 340-40-25-1
Sales commissions payable only if the contract is wonCapitalize if expected to be recovered. A cost incurred regardless of whether the contract is won is not incremental and is expensed.
Costs to fulfill
ASC 340-40-25-5 through 25-8
Onboarding, boarding a merchant, implementation, integration laborCapitalize only if all three criteria are met — relates directly to the contract, generates or enhances resources used to satisfy it, and is expected to be recovered. Otherwise expensed. This is a different test from obtaining costs.
Consideration payable to a customer
ASC 606-10-32-25 through 32-27
Signing bonuses and upfront payments to the merchantGenerally a reduction of the transaction price — not an asset — unless it purchases a distinct good or service at fair value. Capitalizing a signing bonus as an acquisition cost is a common and material error.
"Contract Asset" Means Something Else
A capitalized acquisition or fulfillment cost is not an ASC 606 contract asset. A contract asset (ASC 606-10-45-3) is a conditional right to consideration for services already transferred. A capitalized cost is a deferred cost under ASC 340-40. They sit in different places, amortize differently and are impaired under different models. Label the account "capitalized contract costs" and never let the two share a caption.
Capitalized Contract Costs — Measurement
Asset = incremental costs of obtaining + qualifying fulfillment costs
        (payments to the merchant are excluded — they reduce revenue)

Practical expedient (340-40-25-4): if the amortization period would be
one year or less, obtaining costs may be expensed as incurred. Elect it as a
policy and apply it consistently.

Amortization period: the period of transfer of the related services,
including goods or services under anticipated contracts — i.e. expected
renewals — where the cost relates to them. "Reasonably certain" is the lease
threshold, not this one.

Method: systematic, on the basis consistent with the pattern of transfer.
Straight-line is appropriate only where transfer is itself ratable; a
volume-driven acquiring contract often is not.

Impairment (340-40-35-3): recognize a loss where the carrying amount
exceeds remaining consideration expected less directly related costs still
to be incurred. Reversal is prohibited.

Journal Entries — Revenue Recognition Applied

Gross Revenue Presentation (Principal) — $100M Portfolio at 1.75% MDR
At clearing — Revenue recognition.
Worked deliberately wrong first, then corrected — this is the most common
construction error in the entry.


✗ Incorrect: receivable stated net of interchange only, while the
narrative claims both fees were deducted:
Dr Settlement Receivable     $98,600,000  (labeled "GTV less IC less scheme" — but $100M − $1.4M deducts IC alone)
Dr Interchange Expense       $1,400,000
Dr Scheme Fee Expense         $130,000
  Cr Merchant Payable           $98,250,000  (GTV less MDR $1,750,000)
  Cr MDR Revenue                $1,750,000
Check: Debits $100,130,000 ≠ Credits $100,000,000 — out by exactly the
$130,000 of scheme fees that were named but never deducted.

✓ Correct:
Dr Settlement Receivable     $98,470,000  ($100M − IC $1.4M − scheme $130K)
Dr Interchange Expense       $1,400,000
Dr Scheme Fee Expense         $130,000
  Cr Merchant Payable           $98,250,000
  Cr MDR Revenue                $1,750,000
Total debits = $100,000,000 ✓ · Total credits = $100,000,000 ✓
Acquirer margin = $98,470,000 cash received − $98,250,000 merchant payable = $220,000 (22 bps)
Failure Scenario — Revenue Presentation Restatement Risk
What happens: Acquirer presents interchange pass-through fees net of MDR revenue (i.e., reports only the $220K margin as revenue instead of the full $1.75M MDR). This is the agent presentation. If the acquirer is actually the principal (controls the service, bears credit risk, sets MDR independently), this is a material misstatement of gross revenue — potentially overstating cost ratios and understating revenue by 8x.
Audit risk: Big 4 partner will test the principal-vs-agent determination in Year 1. Weak documentation = audit adjustment. Well-documented = defensible. The memo must exist before the question is asked.

Controller Checklist — Revenue Recognition

Revenue Recognition Close Controls
□ MDR revenue recognized on clearing date (not settlement, not auth)
□ Gross revenue presentation documented in formal technical accounting memo
□ Control conclusion documented per specified service; 55-39 indicators applied as support: (1) primarily responsible ✓ (2) inventory risk ✓ (3) pricing discretion ✓ — credit risk not cited
□ Any new revenue streams (DCC, surcharge, gateway fees) assessed under ASC 606 before first booking
□ Variable consideration (volume discounts, incentives) estimated and constrained per ASC 606-10-32
□ Contract modifications reviewed quarterly — prospective vs. catch-up determination documented
□ Contract cost assets (commissions) amortization schedule current and tied to active contracts
🔍 Controller Lens — Revenue Recognition
WHAT CREATES THE ASSET?Recognizing revenue always has a balance-sheet counterpart. At clearing the MDR credit is matched by the settlement receivable — an unconditional right to consideration. Where the right is conditional on something besides the passage of time, it is a contract asset (606-10-45-3). Where the merchant prepaid, revenue instead draws down a contract liability. Never "no asset."
SOURCE OF TRUTHMPA pricing schedule (MDR rate). Network clearing file (GTV). Internal billing system (invoiced MDR). All three must agree.
TIMINGRecognize on clearing date regardless of when cash settles. Variable consideration (volume discounts) estimated per ASC 606-10-32.
KEY RISKGross vs. net misclassification. Concession booked as revenue correction. New product streams without ASC 606 memo. Contract modification unidentified.

Surcharge Accounting

Surcharging — charging cardholders an additional fee (typically 1–3%) to offset MDR cost — creates a specific revenue recognition question. The treatment depends on who sets the surcharge and who collects it.

Surcharge ModelWho Sets ItRevenue RecognitionJournal Treatment
Merchant-set surcharge (pass-through)Merchant collects from cardholder, included in transaction amountAcquirer recognizes gross (MDR × full transaction including surcharge). Merchant retains the surcharge economics after netting with the MDR charged to the merchant.No separate entry — surcharge flows through normal MDR/GTV entries. Full transaction amount is the revenue base.
Acquirer-facilitated surcharge programAcquirer operates the surcharge program and remits to the merchantOwnership of the surcharge is a contractual question answered before the ASC 606 question. Facilitating collection does not make it the acquirer's consideration. Recognize as revenue only the amount the acquirer is entitled to for its own specified service.See the worked entry below — the merchant payable leg is what makes it balance.
Acquirer-Facilitated Surcharge — $100 Sale, 3% Surcharge ($3.00), 1.75% MDR
Cardholder is charged $103.00. Interchange and scheme fees are assessed on the
full $103.00 (1.40% = $1.44; 0.13% = $0.13). MDR of 1.75% applies to the $100.00
sale = $1.75. Assume the contract gives the surcharge to the merchant.

Dr Settlement Receivable         $101.43  ($103.00 − $1.44 − $0.13)
Dr Interchange Expense            $1.44
Dr Scheme Fee Expense             $0.13
  Cr Merchant Payable               $101.25  ($103.00 − $1.75 MDR)
  Cr MDR Fee Revenue                $1.75
Dr = $103.00 · Cr = $103.00 ✓
Acquirer margin: $1.75 − $1.44 − $0.13 = $0.18

No "Surcharge Revenue" line appears, because under these contract terms the
$3.00 was never the acquirer's. It reaches the merchant inside the payable.

If instead the contract entitles the acquirer to the surcharge (it sets the
rate, keeps the amount, and bears the program obligations), the $3.00 is the
acquirer's consideration: credit Surcharge Revenue $3.00 and reduce the
merchant payable to $98.25. Debits and credits still total $103.00.
The Surcharge Error That Balances Nothing
The tempting entry — debit the receivable for the full amount, credit MDR revenue and credit surcharge revenue — omits the merchant payable entirely. It therefore does not balance, and it recognizes as revenue money the acquirer collected on someone else's behalf. Two separate questions, in order:

1. Whose money is it? Read the merchant agreement and the surcharge program terms. Collecting an amount and being entitled to it are different things.
2. If it is the acquirer's, what did it earn it for? Then apply the control analysis to that specified service like any other revenue stream.

Note also that interchange and scheme fees are assessed on the surcharged total, so a surcharge program raises the acquirer's own cost base even when it produces no acquirer revenue at all.
ASC 606-10-32-2; 606-10-55-36 through 55-39A.
Controller Watch-Out — Surcharge on Debit Cards
Surcharging is prohibited on debit and prepaid cards under Visa and Mastercard network rules. A merchant or acquirer surcharging debit transactions faces network fines and potential program termination. The controller must ensure that any surcharge revenue line is validated against card type — surcharge revenue on transactions where the BIN maps to a debit card is a compliance red flag, not just an accounting issue.

Refund & Reversal Accounting

Refunds and reversals are not the same thing. A reversal cancels a transaction before settlement. A refund returns funds to a cardholder after settlement. Each has a different accounting treatment.

Refund vs. Reversal — Journal Entry Comparison
Reversal (before clearing — void):
Original auth: No GL entry made. Auth is simply removed from open auth log.
No journal entry required. No revenue was ever recognized.

Credit/Refund (after clearing and settlement):
Merchant initiates refund. Network processes as a negative transaction in next clearing file.

$1,000 refund. Scenario A rates. Amounts are unsigned — the Dr/Cr column
carries the direction, so parentheses are not used.


Dr MDR Revenue                         $17.50   (reverses 1.75% earned on the original sale)
Dr Merchant Payable                    $982.50   (recovered from the merchant)
  Cr Interchange Expense                  $14.00   (IC credited back by the network)
  Cr Scheme Fee Expense                   $1.30   (scheme credited back)
  Cr Cash / Settlement Payable      $984.70   (net funds out to the network)
Total Dr = $1,000.00 · Total Cr = $1,000.00 ✓

Cash out is $984.70, not $1,000: the acquirer returns the full $1,000 to the
cardholder but recovers $14.00 of interchange and $1.30 of scheme fees.

Net P&L impact: $17.50 revenue reversed, less $15.30 of costs credited back
= $2.20 margin reversed — 22 bps, exactly mirroring the original sale.
Do Not Assume Every Fee Comes Back
The entry above assumes full credit of both interchange and scheme fees. That assumption is what makes the refund a clean 22-bp mirror image — and it is frequently wrong. Interchange on a credit/refund is generally returned, but scheme and assessment fees vary: some are credited, some are not, and several per-message or per-authorization fees are charged on the refund transaction itself as a new billable event. A refund can therefore cost the acquirer more than the margin it reverses.

Control: verify the actual fee-credit behavior per fee code against the network billing detail, not against the assumption. Where fees are not credited, the P&L impact of a refund exceeds the original spread and the difference belongs in your refund-cost model. Document the assumption in the revenue memo so a reviewer can test it.

Controller note: high refund rates are a revenue leakage indicator. Track refund rate weekly by merchant and set the review threshold from your own portfolio distribution — refund behavior varies enormously by vertical, and a single cross-portfolio percentage will either flood you with false positives or miss the real outliers.
ASC 606-10-32-10 and 32-14; Visa Core Rules (credits and reversals).
Chapter 04

Interchange &
Scheme Economics

Visa and Mastercard interchange categories, assessment fees, network fees, basis points arithmetic, and how every fee tier flows through the acquirer P&L.

Interchange is typically the largest single cost driver in card payments, and on a gross basis it dominates the cost stack — the exact share depends on pricing model, card mix and segment, so derive it from your own cost data rather than a quoted percentage. A controller who cannot read an interchange table, explain qualification criteria, and reconcile interchange billed by the network to the underlying transaction detail is operating blind in the most material line item on the P&L. This section demystifies interchange categories and establishes the analytical framework for scheme economics.

What Is Interchange?

Interchange is a fee paid by the acquirer to the issuer for each card transaction. It compensates the issuer for credit risk, funding cost, fraud losses, and reward program costs. Interchange rates are set by the card networks (Visa, Mastercard) and published in their interchange rate tables — but individual issuers receive the interchange income, not the network itself. The network charges separate scheme/assessment fees for network access and processing services.

Interchange Rate Determinants

Card Type

Consumer debit, consumer credit, rewards credit, signature preferred, commercial card (corporate, purchasing, fleet, T&E). Each tier has distinct interchange economics.

Merchant Category Code (MCC)

The MCC assigned to the merchant determines which interchange category applies. Grocery (5411), gas stations (5541), utility (4900), and government (9XXX) codes often carry preferred rates.

Transaction Entry Mode

Card-present EMV chip, contactless, magnetic stripe, card-not-present (e-commerce), manually keyed. Chip and contactless transactions qualify for better rates; CNP is the most expensive.

Fraud/Authentication Data

Transactions with CVV2 verification, AVS match, and 3DS authentication qualify for downgrade protection and better rate tiers. Missing data elements trigger downgrades.

Visa Interchange Categories — Key Tiers

Illustrative Structure — Not a Current Tariff
Both category tables in this chapter exist to show how interchange is structured — that rate depends on card product, presentment environment, data quality and issuer regulatory status, and that failing a qualification requirement moves a transaction to a more expensive tier. Read them for the mechanics.

Do not read them as prices. Three specific cautions:

Program names drift. Category labels are renamed, split and retired across releases. A name that once identified one rate may now span several cells or no longer exist.
A single rate per "category" is a simplification. Real schedules price by product and qualification criteria together, so one row here can correspond to many cells in the published table.
"Any Credit" is not a real qualification. Downgrade tiers apply through specific data and timing failures, and the resulting rate still depends on the underlying product.

Debit in particular must be split between regulated (Regulation II issuers) and exempt issuers, each with its own table, plus the applicable fraud adjustment and separate CNP treatment. A blended debit rate that ignores issuer mix will not reconcile.

Control: build your cost model from the current published schedule, dated and version-controlled, and refresh it on each network release. Reconcile modeled rates to actual per-transaction interchange from the settlement file monthly — that reconciliation, not a handbook table, is what proves your rate model.
Current published U.S. schedule: Visa U.S.A. Interchange Reimbursement Fees.
CategoryCard TypeRate (illustrative)Per-Item FeeKey Requirements
CPS/RetailConsumer Credit~1.51%$0.10Card-present, swiped/dipped. Rate approximate — Visa updates interchange tables semi-annually; always verify against current published schedules.
CPS/Reward 1Rewards Credit1.65%$0.10Card-present, chip or swipe, standard retail
CPS/Reward 2Signature Preferred1.95%$0.10High-reward cards; card-present
CPS/e-CommerceConsumer Credit CNP1.80%$0.10Card-not-present with full auth data
EIRF (downgrade)Any Credit2.30%$0.10Missing required data elements; late clearing
Standard (floor)Any Credit2.70%$0.10Most restrictive downgrade tier
CPS/DebitConsumer Debit (sig)0.80%$0.15Signature debit, card-present
Regulated Debit (Reg II)Regulated Debit0.05%$0.21Issuer covered by Regulation II (Durbin), ≥$10B assets. Exempt-issuer debit prices separately
Commercial Level 3Corporate/Purchasing1.90%$0.10Requires Level 3 data (line-item detail)
Durbin / Regulation II — Name It Correctly
The Durbin Amendment (Dodd-Frank §1075) is implemented by the Federal Reserve's Regulation II, which caps debit interchange for issuers at or above the $10B asset threshold at a base component plus an ad valorem component, with a separate fraud-prevention adjustment for eligible issuers. This materially reduces debit interchange and is a critical pricing input at high-debit-mix merchants such as grocery and fuel.

Regulation E is a different rule entirely — it governs consumer electronic fund transfer rights, error resolution and disclosures. It has nothing to do with interchange caps. "Reg E debit" as a name for a regulated-debit interchange category is a category error that will be caught immediately by anyone who works in deposits or disputes.

The cap components are set by Federal Reserve rulemaking and have been the subject of proposed revisions; confirm the current figures against the Board's rule before using them in a pricing model or a cost accrual. Note also that exempt-issuer debit — issuers below the threshold — is not capped and prices from the network's exempt tables, so a portfolio's blended debit cost depends on its issuer mix, not on the cap alone.

Scheme/Assessment Fees — Visa

Separate from interchange, the networks charge assessment and processing fees to acquirers for network access, switching, and authorization services. These are typically billed monthly on a complex schedule and are a frequent source of reconciliation complexity.

Do Not Use These Rates — Use Your Own Billing Schedule
Scheme fee tariffs are participant-specific commercial terms. They are not published in full in the public rulebooks, they differ by acquirer, region, product, currency and volume tier, and they change on network release cycles. Any rate quoted in a handbook is stale the moment it is printed.

A second trap is attributing a fee to the wrong network. NABU — Network Access and Brand Usage — is a Mastercard fee, and it is not an acronym for "Network Acquirer Processing Fee." Visa's per-authorization charge is the Acquirer Processing Fee (APF). Mixing the two produces an accrual that reconciles to neither network's invoice and a variance that no one can explain, because the fee being modeled does not exist on the network it was booked against.

Control — validate each fee code on six attributes: (1) issuing network, (2) the billable message or event that triggers it, (3) geography and cross-border status, (4) currency, (5) rate and calculation basis, (6) effective date. Source every one to your current network billing schedule, hold them in a dated fee master, and re-verify on each network release. Treat the column above as a map of fee types, never as a price list.
Fee-collection framework: Visa Core Rules §1.11.1; Mastercard Transaction Processing Rules. Neither publishes the complete commercial tariff.
Fee TypeBasisRate (approx.)Notes
Acquirer Assessment (Service Fee)Gross sales volume≈0.13%Visa. Domestic credit/debit; rate varies by product
ISA (International Service Assessment)Cross-border volumeVariesVisa. Rate depends on card, transaction type and settlement currency
APF (Acquirer Processing Fee)Per authorizationVariesVisa. Charged on authorization messages — not a clearing-based fee
Fixed Acquirer Network Fee (FANF)Per MID / locationVariableVisa. Monthly, tiered by merchant type and volume
NABU (Network Access and Brand Usage)Per transactionVariesMastercard — not Visa. Listed here only to prevent the common misassignment
Misuse of AuthorizationPer occurrenceVariesBoth networks operate a fee of this type; triggers and amounts differ
Zero Floor Limit / non-authorizedPer transactionVariesCharged where a cleared transaction has no matching valid authorization

Basis Points Arithmetic

All interchange and scheme fee economics are expressed in basis points (bps) for comparability. One basis point = 0.01% = $0.10 per $1,000 of transaction volume. When analyzing acquirer margins, the controller must convert per-item fees to an effective basis-point equivalent based on average ticket size.

Per-Item Fee → Effective BPS Conversion
Effective BPS = (Per-Item Fee / Average Ticket Size) × 10,000

Example: $0.10 per item at $45 avg ticket = (0.10 / 45) × 10,000 = 22.2 bps effective
At $200 avg ticket: (0.10 / 200) × 10,000 = 5.0 bps effective

Mastercard Interchange Categories — Key Tiers

Mastercard's interchange structure parallels Visa's but uses different tier names and rate levels. Controllers managing mixed Visa/MC portfolios must maintain separate rate models — blending them produces inaccurate cost forecasts.

CategoryCard TypeRate (approx.)Per-Item FeeKey Requirements
Merit IIIConsumer Credit1.58%$0.10Card-present, chip or swipe, standard retail; MC's primary CP qualified tier
WorldWorld/World Elite Credit1.89%$0.10Premium consumer card; card-present; higher rewards tier
World EliteWorld Elite Credit2.10%$0.10Top-tier premium card; card-present
Merit I (CNP)Consumer Credit CNP1.89%$0.10Card-not-present, full authorization data, e-commerce
Electronic (downgrade)Any Credit1.90%$0.10Electronically submitted but misses Merit III data requirements
Standard (floor)Any Credit2.95%$0.10Floor rate; most expensive downgrade tier — 137 bps above Merit III (2.95% − 1.58%)
Debit Core (Consumer)Consumer Debit (sig)1.05%$0.15MC signature debit, card-present, non-regulated issuer
Debit RegulatedRegulated Debit0.05%$0.21Durbin-regulated issuer (≥$10B assets); capped by federal regulation
Corporate Data Rate IICorporate/Purchasing2.05%$0.10Requires Level 2 data: tax amount, customer code, merchant postal code
Corporate Data Rate IIICorporate/Purchasing1.80%$0.10Requires Level 3 data: full line-item detail; best commercial rate
Visa vs. Mastercard Rate Comparison — Controller Insight
On the illustrative rates in these tables, Mastercard's Standard floor of 2.95% sits above Visa's 2.70%, so identical downgrade behavior costs more on MC volume. Monitoring downgrade rates by network separately is non-negotiable in a well-run acquirer finance function.

But state the impact correctly. The gap between Standard and Merit III is 137 bps (2.95% − 1.58%). That is the penalty on each downgraded transaction — it is not the portfolio impact. A 5% downgrade rate means only 5% of volume pays that penalty:
Weighted impact = affected share × rate gap
                 = 5% × 137 bps = 6.85 bps on total MC volume

On $100M of MC volume: $100M × 0.0685% = $68,500 of excess cost.
Quoting "~125 bps of excess cost" for this scenario overstates the portfolio impact by roughly 18×. On a 22-bp book, a genuine 125-bp cost increase would not be a variance to investigate — it would be an extinction event. A number that implausible should stop the review before it reaches the deck.

The same discipline applies to mix shifts. Moving one percentage point of volume between a 27-bp cost and a 205-bp cost changes blended cost by 1% × (205 − 27) = 1.78 bps at fixed price — not 30+ bps. Always separate the rate effect on affected volume from the weighted effect on total volume, and never add a mix line on top of a blended-rate effect that already captures it (see the bridge convention in Chapter 9).

MDR Pricing Models — How Acquirers Structure Merchant Pricing

Acquirers charge merchants under one of three primary MDR structures. Understanding the pricing model is prerequisite to revenue recognition, margin analysis, and interchange cost allocation. Each model has distinct controller implications.

Interchange-Plus (I++)

Merchant pays actual interchange cost (whatever rate their transactions qualify for) plus a fixed acquirer markup expressed in bps and/or per-item fee. E.g., "Interchange + 30bps + $0.10." Acquirer margin is fixed and transparent. Revenue recognition is straightforward — variable consideration equals actual interchange by transaction; acquirer markup is fixed. Favored by sophisticated merchants and industry analysts for transparency.

Blended / Flat Rate

Merchant pays a single fixed percentage regardless of card type or interchange tier. E.g., "2.75% + $0.30." Acquirer's margin varies with card mix — higher-interchange cards reduce margin; lower-cost debit transactions increase it. Revenue recognition is simpler but margin forecasting requires card mix modeling. PayFac/aggregator model (Stripe, Square) typically uses flat-rate.

Tiered (Qualified / Mid-Qual / Non-Qual)

Transactions are bucketed into 3–4 tiers (Qualified, Mid-Qualified, Non-Qualified) with escalating rates. Common in legacy ISO and community bank portfolios. Highly opaque — acquirer sets tier definitions; merchants often don't know which bucket their transactions fall into. From a controller perspective, tier mapping must be documented; tier reclassification risk is a recurring audit point.

Subscription / SaaS Pricing

Fixed monthly fee covers all processing at interchange cost (pass-through). Merchant pays a flat subscription plus actual interchange. Acquirer revenue is the subscription fee; margin is predictable. Growing model for high-volume merchants. Creates a distinct revenue recognition question: subscription fee recognized ratably over the month; interchange is a pure pass-through (agent presentation).

Controller Revenue Recognition Implication
Under ASC 606, the pricing model directly shapes the gross vs. net analysis. In an I++ structure, the interchange component is clearly a pass-through (net presentation); the acquirer markup is gross revenue. In a blended rate, the entire MDR may be presented gross if the acquirer controls the service and bears risk — but requires stronger principal documentation. In subscription pricing, the subscription fee is gross revenue; interchange is explicitly net. Get this right in your revenue recognition memo or your gross revenue figure is materially misstated.

Bundled MDR — From Statement to Sub-Ledger

The MDR shown on a merchant statement is a single number. The accounting it produces is not. A 2.30% blended rate looks atomic to the merchant — one percentage applied to gross volume — but on the acquirer's books it splits into three economically distinct components, governed by three different parts of ASC 606, posted across multiple GL accounts, and reconciled across at least three independent data sources. This section walks the dollar from the merchant statement through to the variance accounts that surface margin compression — the architecture every controller needs to understand before they can defend the revenue line.

1. The Anatomy of a Bundled MDR

Every bundled MDR contains three components: interchange paid to the issuing bank, network assessments paid to Visa and Mastercard (or the equivalent on closed-loop networks), and the acquirer's residual spread. The proportions vary by card type and merchant category, but the structure is constant. For a representative $100 retail credit transaction at 2.30% blended pricing, the decomposition looks like this:

Figure · Anatomy of a $2.30 MDR — Three-Component Decomposition
$2.30 BLENDED MDR · 230 BPS · BILLED TO MERCHANT ON $100 TX $1.65 71.7% · 165 BPS $.13 5.7% $0.52 22.6% · 52 BPS Interchange AGENT · PASS-THROUGH Assessments AGENT Acquirer Spread PRINCIPAL · NET REVENUE THREE DEFENSIBLE P&L PRESENTATIONS · SAME ECONOMICS COGS-STYLE · PRIMARY MDR Revenue (gross) $2.30 Cost of revenue: Interchange ($1.65) Assessments ($0.13) Gross profit $0.52 Bank acquirer house view. IC and assessments above the gross profit line as period costs — never netted, never contra. PURE NET Net merchant disc rev $0.52 IC and assessments never touch the income statement. PAYABLE TO ISSUER $1.65 PAYABLE TO NETWORK $0.13 balance sheet only Post-606 trend for processors with weaker principal indicators. CONTRA-REVENUE · LEGACY Gross MDR revenue $2.30 Less: Interchange ($1.65) Less: Assessments ($0.13) Net MDR revenue $0.52 Pre-606 dominant view. Implies netting against revenue rather than treating IC as a true period cost. Now rare.
Scenario Note — This Chapter's Worked Figures
The bundled walkthrough below runs on Scenario B (2.30% MDR, 1.65% interchange — see Chapter 2) with scheme fees at 0.13% rather than Scenario B's 0.14%, producing a 52-bp spread instead of 51. This is a deliberate, disclosed variant kept so the per-$100 figures in the diagrams stay round. Do not carry the 52-bp result back into a Chapter 2 journal.

It is tempting to summarize the decomposition as "interchange and assessments are agent positions, the spread is the principal position." That framing is intuitive, widely repeated, and does not survive contact with the standard — because it reaches an agency conclusion and then presents gross anyway, which are mutually exclusive outcomes.

You Cannot Be an Agent and Present Gross
Gross and net are not presentation preferences layered on top of a control conclusion. They are the conclusion. If the acquirer controls the specified service, it is a principal and reports gross revenue with interchange as a cost. If it does not, it is an agent and reports the net fee. Concluding "agent" and then electing a gross cost-of-revenue presentation because it better reflects the economics is not a defensible position — it reports as revenue amounts the entity has already concluded were never its consideration.

Three further corrections to the common framing:

The indicators live in 55-39, not 55-37, and credit risk is not among them — ASU 2016-08 removed it. Merchant credit exposure is commercially central to acquiring and analytically irrelevant to this question. Citing it is the fastest way to lose a reviewer's confidence in the whole memo.
The question is asked per specified service. "Interchange" is not a service — it is a price component. Identify what the acquirer promised the merchant, then ask who controls it. A single contract can produce a principal conclusion on processing and an agent conclusion on a separately arranged service.
No pricing discretion over a cost input is not agency. Manufacturers do not set commodity prices and remain principals. What matters is control of the promised service, not who sets the cost.

2. How the Conclusion Reaches the P&L

Once the control analysis is done, the income statement follows from it. The genuine question is not which of three presentations to elect, but whether the analysis supports principal or agent — and then how to display the result usefully.

Control conclusionExternal presentationPer $100 transaction
Principal — acquirer controls the processing serviceGross MDR as revenue; interchange and assessments as cost of revenueRevenue $2.30 · Cost $1.78 · Gross profit $0.52
Agent — acquirer arranges for others to provide itNet fee as revenue; pass-through amounts never enter the income statementRevenue $0.52
Contra Accounts Are a Mechanism, Not a Third Answer
Contra-revenue accounts are frequently described as a separate, disfavored "presentation." They are better understood as bookkeeping machinery. An entity that has concluded it is an agent may perfectly properly record gross MDR and a contra account that nets it down, provided what is presented in the financial statements is the net amount. That is a valid implementation of a net conclusion, not a policy in competition with it.

The same machinery is genuinely useful internally regardless of the external answer: FP&A and pricing analytics need gross-to-net visibility, and a sub-ledger that carries gross MDR, interchange and assessments separately supports both the external presentation and the margin analytics. The error is not using contra accounts — it is letting the account structure decide the presentation instead of the control conclusion.

What this handbook can and cannot tell you: it can set out the analysis and show how each conclusion flows through the journals. It cannot tell you your answer, because that depends on your contracts, your network membership, your operational responsibility and your pricing authority. Claims about what "most acquirers" or "the industry" do are not evidence for your conclusion and should not appear in your memo — if peer practice is relevant, cite specific dated filings.
ASC 606-10-55-36 through 55-39A; FASB ASU 2016-08.

3. IC+ vs Tiered — Mix Risk Mechanics

The four pricing structures introduced in MDR Pricing Models above deliver the same ASC 606 conclusion — principal/agent decomposition produces a net spread that is the acquirer's true revenue. But they distribute economic risk very differently across the merchant relationship, and the difference shows up not in revenue recognition but in margin volatility.

Under interchange-plus, the merchant absorbs interchange volatility; the acquirer earns its fixed plus regardless of card mix. Under tiered, the acquirer absorbs that volatility: the spread expands when low-cost cards run at high tier rates (the "downgrade benefit") and compresses when high-cost cards run at low tier rates. The chart below shows how dramatically this can swing for the same merchant under the same headline rates, depending on which card types actually transact.

Figure · IC+ vs Tiered — Acquirer Spread by Card Mix
SAME MERCHANT · SAME $100 TX · IC+ PLUS = 35 BPS · TIERED Q 1.79% / MQ 2.29% / NQ 2.95% IC+ 35 BPS 0 25 50 75 100 125 150 BPS 152 54 18 24 55 35 Regulated Debit IC 27 BPS · TIER Q Non-Reg Debit IC 125 BPS · TIER Q Standard Credit IC 161 BPS · TIER Q Rewards Credit IC 205 BPS · TIER MQ Premium Credit IC 240 BPS · TIER NQ Corporate Card IC 260 BPS · TIER NQ Downgrade benefit zone — low-cost IC running at high tier rates produces spread well above the IC+ baseline; acquirer absorbs none of the cost (regulated debit at qualified is the extreme). Compression zone — high-cost IC running at qualified or mid-qual eats the spread; acquirer margin loss.

The arithmetic is mechanical but the consequences are not. A regulated debit card on a tiered qualified rate produces 152 bps of acquirer spread — nearly five times the IC+ benchmark of 35 bps — because the merchant pays the qualified tier rate (1.79%) while the underlying interchange is just 27 bps. That 152 bps is real revenue, fully booked, fully recognized, but exists only because tiered pricing decoupled the merchant's billed rate from the underlying interchange cost. A standard credit card on the same qualified tier produces only 18 bps of spread because the underlying interchange is 161 bps — nearly the entire qualified tier rate is consumed by interchange, leaving the acquirer with only the difference between 1.79% and 1.61% to work with.

This is why tiered pricing portfolios show wider margin distributions than IC+ portfolios at the same average MDR, and why FP&A teams at tiered acquirers track card mix as obsessively as they track volume — margin moves with mix even when gross MDR does not, a dynamic that has no analog in IC+ pricing.

Size the Mix Effect Correctly
The sensitivity is real but frequently overstated by an order of magnitude. Shifting one percentage point of volume from regulated debit (27 bps of interchange) to rewards credit (205 bps) at a fixed billed rate changes blended interchange cost by:
1% × (205 bps − 27 bps) = 1.78 bps of margin compression
Not 30 bps. To compress margin by 30 bps through mix alone at that cost differential you would need to move roughly 17 percentage points of volume — a portfolio transformation, not a quarterly drift. Confusing the rate gap (178 bps) with the weighted portfolio effect (1.78 bps) is the same error as the downgrade calculation earlier in this chapter, and it produces mix-risk narratives that cannot be reconciled to the actual P&L. Always multiply the rate differential by the share of volume that actually moved.
Controller Watch-Out — The Downgrade Benefit Is Real Revenue, But Not Sustainable
Acquirer FP&A teams sometimes treat downgrade benefit as core margin and bake it into forward forecasts. This is dangerous: downgrade benefit is structurally fragile. Network mandates that improve interchange transparency (PINless debit routing under Durbin, Reg II expansion to digital wallets), merchant migration to IC+ for sophistication or audit reasons, and tier reclassification by acquirers themselves (often forced by competitive pressure) all compress the benefit over time. Best practice: track downgrade benefit as a separate line in margin attribution, monitor its trend, and exclude it from forward-looking margin guidance unless the structural drivers are explicitly modeled.

4. Bundled Monthly Recognition — When Pricing Becomes Subscription

Subscription pricing models — common in modern merchant services platforms (Helcim, Stax, Payment Depot) and growing in mid-market acquiring — introduce a recognition wrinkle that per-transaction models do not. The merchant pays a flat monthly fee covering all processing at interchange cost, plus a pass-through of the interchange itself. The bundled monthly fee is not earned at any single transaction event; it is earned over the service period.

Under ASC 606-10-25-27(a), this is a stand-ready performance obligation: the acquirer is contractually obligated to be ready to process transactions throughout the month, regardless of whether the merchant actually generates volume. Revenue is recognized ratably across the service period — typically straight-line daily — while interchange and assessments continue to accrue per-transaction as actual volume runs. The two recognition patterns interact across the cycle as follows:

Figure · Bundled Monthly Recognition — 30-Day Cycle, $100M GTV
$2.3M BUNDLED FEE · IC ACCRUES PER-TX · NET REVENUE RECOGNIZED RATABLY IC accrual (per-tx) Revenue recognition (ratable) $2.3M $1.65M $1.15M $520K $0 $1.65M $520K SETTLE Day 1 5 10 15 20 25 30 IC accrues per-tx — jagged, volume-driven Revenue recognized ratably — 1/30th per day DAY 1–30 · Daily IC payable accrual against estimated bundled spread (stand-ready PO). DAILY RATABLE · $520K ÷ 30 = $17,333/day net revenue (constrained estimate per ASC 606-10-32-11). DAY 30 SETTLE · Cash receipt $2.3M; clear IC and assessment payables; book true-up to actual.

Two accounting consequences follow, and a third that is commonly asserted but does not hold.

First, the recognition pattern is over time rather than point in time for the stand-ready element, requiring a ratable accrual across the service period against the eventual cash receipt.

Second, the pass-through element must be analyzed separately. A flat subscription fee and an interchange pass-through are different promises with different measurement. Do not merge them into one all-in revenue pool — Chapter 2's fee waterfall and this subscription model describe different contracts and cannot share a figure.

The Spread Is Not Variable Consideration
It is frequently said that under bundled pricing "the spread becomes variable consideration," because the acquirer now absorbs interchange volatility. The commercial observation is right; the accounting conclusion is wrong, and it matters.

Variable consideration is about the amount the customer will pay you. ASC 606-10-32-5 through 32-13 addresses consideration that varies — discounts, rebates, refunds, incentives, performance bonuses, contingencies. If the merchant owes a fixed monthly subscription fee, the transaction price is fixed. It does not become variable because your costs moved.

Variable supplier costs change margin, not revenue. When interchange rises under a fixed-fee contract, revenue is unchanged and gross profit falls. There is nothing to estimate and nothing to constrain, because the constraint exists to prevent recognizing customer consideration that may later reverse — and no reversal of customer consideration is in prospect here. Applying the constraint to a cost movement suppresses revenue the entity is unconditionally entitled to.

When it genuinely is variable consideration: the contract contains a true-up to the merchant, a volume-based rebate, a price concession, a performance credit, or a cap or floor that changes what the merchant owes. Those are variable and must be estimated and constrained. A cost pass-through billed at actual is also variable in amount — but it is variable because the billed amount varies, not because the cost does.

Practical test: ask whether the amount the merchant owes can change after the period. If only your cost can change, you have a margin exposure and a forecasting problem, not a revenue measurement problem.
ASC 606-10-32-2; 32-5 through 32-13; 25-27; 25-31.

Third, a month-end true-up remains a real control point — but be precise about what it is. Reconciling accrued interchange and assessments to actual network settlement is a cost reconciliation, and its variance belongs in cost of revenue, not in a contra-revenue reserve. Only where the contract itself adjusts what the merchant owes does a true-up touch revenue. Booking a cost variance through contra-revenue misstates both lines while leaving gross profit coincidentally correct — which is precisely why it survives review for so long.

For practical purposes, most subscription acquirers maintain a daily revenue accrual based on the bundled fee divided by days in the period, with the variance posting on the last business day of the month. The constraint analysis is documented at the contract level (most subscription contracts have IC volatility clauses that protect the acquirer from extreme mix shifts, narrowing the constraint) and refreshed quarterly.

5. The Sub-Ledger Reconciliation Engine

The decompositions, presentations, and recognition patterns above only work if a daily reconciliation engine sits between the acquirer's three primary data sources — the network settlement files, the merchant billing system, and the treasury cash position — and produces a single source of truth that posts to the GL. This engine is the sub-ledger, and its variance accounts are the diagnostic surface where margin compression, downgrade leakage, and tier mis-assignments become visible before they reach the financial statements.

Figure · Sub-Ledger Reconciliation Engine — Inputs, Decomposition, Outputs
INPUTS Network Settlement File Visa and Mastercard clearing files actual IC · scheme · per tx DAILY Merchant Billing System Acquirer billing engine gross MDR · tier × vol · recurring DAILY / MONTHLY Treasury & Cash Settlement & merchant funding net cash receipts · ACH funding DAILY DAILY SUB-LEDGER PER MERCHANT · PER DAY · PER PRICING ARRANGEMENT SOURCE FIELD DAILY · $100M MONTHLY PORTFOLIO [ Billing ] Gross MDR billed $76,667 [ Settlement ] Less: Interchange paid ($55,000) [ Settlement ] Less: Scheme assessments ($4,333) [ Computed ] = Net acquirer spread $17,333 true-up POST TO GL Net Discount Revenue P&L · PRINCIPAL Interchange Payable BS · AGENT Assessment Payable BS · AGENT Settlement Payable BS · MERCHANT VARIANCE ACCOUNTS IC Variance billed vs actual downgrade leakage Scheme Variance timing · true-up monthly assessment lag Tier Reclass post-period adj qualification true-up Three-way tie-out daily: sub-ledger ↔ settlement file · sub-ledger ↔ merchant billing · sub-ledger ↔ treasury cash · then rolled to GL.

The architecture is mechanically simple: three input streams flow into a daily sub-ledger that computes the per-merchant decomposition, posts the four core balances to the GL (net discount revenue, interchange payable, assessment payable, settlement payable), and routes any variances to three dedicated variance accounts. Interchange variance captures the difference between what the merchant was billed (under IC+ pass-through) and what was actually paid to the issuer — the downgrade leakage that consumes margin under data-quality failures. Scheme variance captures the timing differences between estimated daily assessments and actual monthly billing receipts from Visa and Mastercard. Tier reclass reserve, used only under tiered pricing, captures post-period qualification adjustments that re-tier transactions after the original recognition.

The control story is the three-way tie-out: every business day, the sub-ledger must reconcile to the network settlement files (interchange and assessment side), to the merchant billing engine (gross MDR side), and to the treasury cash position (settlement side). Any of the three breaks open is a SOX-relevant exception that must be aged, escalated, and resolved before the books close. A common pattern is to automate the first two and keep a manual review on the third; confirm what your own control environment actually does.

The sub-ledger is also where the principal/agent decision lives operationally. Under net presentation, the sub-ledger never posts interchange to revenue accounts — it posts directly from the cash receipt to the issuer payable, with only the spread routing through revenue. Under COGS-style presentation, the sub-ledger posts gross MDR to revenue and interchange to a separate cost-of-revenue line. Whichever view is documented in the ASC 606 memo dictates the sub-ledger configuration; changing the configuration without updating the memo is a material weakness waiting to happen.

Controller Checklist — MDR Mechanics
□ ASC 606 memo on file documenting principal indicators for MDR revenue (control, credit risk, pricing discretion)
□ P&L presentation choice (COGS-style / pure net / contra-revenue) explicitly stated in the memo
□ Pricing model inventory by merchant: IC+, blended, tiered, subscription — with corresponding recognition treatment for each
□ Variable consideration constraint applied to subscription/bundled-monthly contracts; constraint refreshed quarterly
□ Daily three-way reconciliation: settlement file ↔ billing engine ↔ treasury cash, breaks aged with escalation thresholds
□ Variance accounts (IC, scheme, tier reclass) reviewed at month-end, trends tracked over rolling 6-month windows
□ Downgrade benefit (tiered portfolios only) identified and reported separately from intended margin in FP&A attribution
□ Sub-ledger configuration matches the ASC 606 memo's presentation choice — documented and tested annually

PCI DSS — Controller Cost Awareness

Payment Card Industry Data Security Standard (PCI DSS) compliance is a non-negotiable requirement for all entities that store, process, or transmit cardholder data. For the acquiring controller, PCI DSS creates two direct financial exposures: (1) compliance costs — QSA assessments, penetration testing, infrastructure upgrades, and tokenization investments, which are recurring operating expenses; and (2) non-compliance fines — Visa and Mastercard can levy monthly fines on acquirers for merchants in their portfolio who are non-compliant or who suffer a breach. These fines ($5,000–$100,000/month per scheme) flow directly through the acquirer P&L and must be tracked in the scheme fee reconciliation. Non-compliance liability clauses in the MPA determine whether the fine can be passed to the merchant.

Pricing Implication — Per-Item Fee Math
Per-item fee structures heavily penalize high-transaction-count/low-ticket merchants (QSR, coffee, small retail). A $0.10 per-item fee at a $4 average ticket = 250 bps effective — before the percentage rate. Acquirers pricing these merchants must build effective rates well above the stated percentage. This is why a coffee shop's economics look radically different from a luxury retailer at the same headline MDR.

Journal Entries — Interchange Cost Accounting

Interchange as Expense — Standard Model ($100M GTV)
At clearing (interchange accrual — network settlement file):
Dr Interchange Expense             $1,400,000  (1.40% of $100M)
  Cr Interchange Payable / Settlement  $1,400,000

At settlement (cash flows to issuer via network):
Dr Interchange Payable              $1,400,000
  Cr Cash — Settlement Account        $1,400,000

Note: Interchange is NEVER contra-revenue for the acquirer.
It is a cost of revenue on the income statement.
Netting it against MDR revenue = misstatement of gross revenue and gross margin.
Failure Scenario — Interchange Downgrade Storm
What happens: A large e-commerce merchant switches to a new gateway that fails to include CVV and AVS data in clearing messages. All transactions downgrade from CPS/e-Commerce (1.80%) to EIRF (2.30%) — a 50 bps increase. On $20M/month merchant volume, that's $100,000/month in excess interchange cost that was not in budget, not in the accrual model, and not visible until the billing statement arrives 20 days after month-end.
Control: Run weekly interchange cost % by merchant. Any merchant where actual blended rate exceeds budget by >10 bps triggers a downgrade analysis — pull clearing detail, identify missing data elements, escalate to merchant operations.

Controller Checklist — Interchange & Scheme Fees

Interchange Close Controls
□ Interchange expense accrued from network settlement file (not estimated)
□ Downgrade rate monitored weekly: EIRF + Standard volume / total volume <2%
□ Scheme fee accrual model covers all fee categories in CBS/MCBS
□ Any new fee line item in billing investigated before true-up posted
□ Interchange never netted against MDR revenue in income statement
□ FANF accrual model updated quarterly for MID count and tier changes
□ Durbin-eligible debit volume identified and IC modeled separately at capped rate
□ Network incentive/rebate accrual modeled at full-year volume trajectory, updated monthly
🔍 Controller Lens — Interchange & Scheme Economics
WHAT CREATES THE LIABILITY?Each cleared transaction creates an interchange obligation to the issuer (via network) and a scheme fee obligation to the network. Both are period costs — never contra-revenue.
SOURCE OF TRUTHNetwork settlement file for interchange. CBS/MCBS billing statement for scheme fees (received 20 days post-month). Your accrual model bridges the gap.
TIMINGInterchange expense = clearing date (same as revenue). Scheme fees = billed monthly in arrears; quarterly fees billed 30–45 days post-quarter. Always accrue; always true-up.
KEY RISKDowngrade rate spike (missing data elements). Card mix shift (rewards/commercial replaces debit). New FANF tiers. Quarterly network fees arriving in lump sum.

3-Party vs 4-Party Networks — The Accounting Difference

Visa and Mastercard operate 4-party networks — issuer and acquirer are separate entities, interchange flows between them. American Express and Discover operate 3-party (closed-loop) networks — Amex is simultaneously the network, the issuer, AND often the acquirer. This structural difference creates fundamentally different accounting for the acquirer.

4-Party vs 3-Party Network — Settlement Flow Comparison
4-PARTY (VISA / MASTERCARD) Cardholder $100 spend Issuer Bank Chase / BofA Visa / MC Network only Acquirer pays IC $1.40 Merchant receives $98.25 auth request IC $1.40→issuer 3-PARTY (AMEX / DISCOVER) Cardholder $100 spend AMEX Network + Issuer + often Acquirer Merchant no IC split disc. rate only No interchange flows. Amex charges merchant a discount rate (2.5–3.5%) — keeps all of it.
Controller Accounting Difference — $100 Amex vs Visa Transaction
Visa (4-party) — Acquirer books:
Dr Settlement Receivable     $98.47  (net of IC $1.40 + scheme $0.13)
Dr Interchange Expense       $1.40
Dr Scheme Fee Expense         $0.13
  Cr MDR Revenue                $1.75
  Cr Merchant Payable            $98.25

Amex (3-party, Amex as acquirer) — No acquirer books this:
Amex settles directly with the merchant. The "acquirer" in the traditional sense
is Amex itself. For merchants, Amex settlement arrives separately from Visa/MC.
If a third-party acquirer processes Amex under OptBlue program:
Dr Settlement Receivable     $97.20  (Amex pays net after discount rate ~2.80%)
Dr Amex Discount Expense     $2.80   (NOT interchange — Amex's own fee)
  Cr MDR Revenue                $3.00   (acquirer's MDR on Amex volume)
  Cr Merchant Payable            $97.00

Key difference: Amex discount ≠ interchange. No issuer bank receives it.
Amex keeps the spread. The acquirer's P&L on Amex volume uses "Amex Discount
Expense" not "Interchange Expense" — separate GL account, separate reporting.
Controller Note — Amex OptBlue vs Direct
Small-to-mid merchants accept Amex via OptBlue (third-party acquirer processes). Large merchants ($1M+ Amex volume) may have a direct relationship with Amex. In OptBlue, the acquirer pays Amex a discount rate and marks up to the merchant. In direct, the merchant and Amex negotiate directly — the acquirer may not touch Amex volume at all. Know which model your merchants use before building the scheme fee accrual model. Mixing OptBlue and direct Amex volume in one cost line produces an inaccurate effective rate.
Chapter 05

Reserves
& Risk

Rolling, capped, and upfront reserve structures; calculation methodology; and the ASC 450 framework for controller booking, release, and contingent liability governance.

Reserves are the primary financial control mechanism acquirers use to protect against merchant credit exposure. When a merchant fails — through insolvency, fraud, or operational disruption — and there are outstanding chargebacks or refund obligations, the acquirer is the liable party under network rules. The reserve is the buffer between that exposure and the acquirer's P&L. For the controller, reserves touch three distinct accounting domains: the liability assessment (ASC 450), the funding mechanics (settlement), and the disclosure framework (ASC 275).

Reserve Types

Rolling Reserve

A percentage of each settlement funding is withheld and held for a defined period (commonly 90–180 days). After the holding period, funds are released unless chargebacks exist. Most common reserve structure for ongoing merchant relationships.

Capped Reserve

Rolling reserve withheld until a maximum target balance is reached (e.g., 10% of 90-day volume). Once capped, settlement is fully funded; the reserve sits idle until a triggering event (merchant closure, elevated CB rates) or scheduled release.

Upfront (Fixed) Reserve

A single lump-sum amount held at account inception, typically for high-risk onboarding scenarios. Funded via initial settlement hold or direct merchant deposit. Often used in conjunction with a rolling reserve for highest-risk merchants.

Dynamic Reserve

Reserve percentage and target balance adjusted dynamically based on real-time risk signals: chargeback rate spikes, fraud alerts, processing velocity anomalies, or exogenous events. Requires governance framework for adjustment authorization.

Reserve Calculation Methodology

Rolling Reserve Target Calculation
Reserve Target = Volume per period × Number of periods in the hold window × Reserve %

Example (90-day rolling, 10% rate):
Monthly volume: $1,000,000
Periods in window: 3 months
Reserve target: $1,000,000 × 3 × 10% = $300,000

Monthly withholding to reach target: $1,000,000 × 10% = $100,000/month
Target reached in: 3 months of withheld settlements

Equivalently, using an already-windowed basis:
90-day volume $3,000,000 × 10% = $300,000   — but then do NOT
multiply by the window again.
Dimensional Trap — Do Not Apply the Window Twice
Written as "rolling volume basis × reserve % × exposure window," the formula silently invites a double count: if the volume basis is already 90-day volume, multiplying by a 3-month window again produces a $900,000 target — triple the correct figure. Over-holding on that scale is not a conservative error. It starves merchant cash flow, breaches the funding terms in the MPA, and creates a real commercial and legal exposure of its own.

State the basis explicitly every time: per-period volume × number of periods × rate, or windowed volume × rate. Never both.
A Contractual Hold Target Is Not an Expected Loss
This calculation sizes how much merchant cash you are contractually entitled to hold. It does not estimate what you expect to lose, and the two should never be conflated in either direction. A merchant can have a fully funded $300,000 reserve and still present an expected credit loss that requires an allowance; another can have no reserve and no expected loss at all. Size the hold from the agreement and the exposure window; measure loss under the applicable accounting model (see the three-records framework below).

The exposure window is the critical variable: the maximum period over which disputes or returns could still be presented after a merchant stops processing. It is not a single number. Dispute rights run from different start events depending on the dispute condition — transaction date, processing date, delivery or service date, or the date the cardholder became aware — and the permitted period, along with regional exceptions, varies by condition. Delayed-delivery verticals such as travel, events, subscriptions and custom goods carry materially longer tails, which is why they are underwritten differently.

Build the Window From Conditions, Not From a Rule of Thumb
A single portfolio-wide figure — "120 days" — will be simultaneously too long for some conditions and far too short for others, and it cannot be defended to an auditor or a merchant. Build a condition-level matrix from the current network dispute rules: for each dispute condition, the clock start event, the maximum period, and the regional exceptions. Weight it by your own portfolio's dispute-condition mix to derive an effective window, and re-verify it on each rules release.
Dispute conditions and time limits: Visa Core Rules §11; Mastercard Transaction Processing Rules.

ASC 450: Contingency Accounting for Reserves

ASC 450-20 governs the accounting for loss contingencies. For acquirer reserves, the relevant question is: does the acquirer have a probable and estimable loss exposure from a specific merchant's chargeback or insolvency risk?

ASC 450 Two-Condition Test
A loss contingency must be accrued when both conditions are met: (1) it is probable that a liability has been incurred as of the balance sheet date, and (2) the amount of the loss can be reasonably estimated. "Probable" under ASC 450 is interpreted as "likely to occur" — not merely possible. This is a higher bar than IFRS "more likely than not."

For a healthy, operating merchant with no abnormal chargeback history, the standard reserve hold (rolling or capped) is not a loss contingency — it is a refundable deposit held as a liability (Merchant Reserve Liability). But it does not follow that nothing else is required. The reserve is the merchant's money; the acquirer's own exposures are accounted for separately, and some of them require a loss estimate from day one regardless of merchant health.

Three Records, Three Standards — Keep Them Apart
Nearly every reserve error in acquiring comes from collapsing these into one balance. They have different owners, different standards and different triggers.
#RecordWhose money / riskStandard & trigger
1Merchant Reserve Liability — funds withheld from settlement or deposited by the merchantThe merchant's funds, held by the acquirer subject to a refund obligationA liability from inception. Derecognized only when the obligation is discharged (ASC 405-20-40-1). Never a P&L reserve, never an expense when created.
2Allowance on acquirer receivables — amounts the merchant owes the acquirer (fees billed in arrears, chargebacks funded on the merchant's behalf, negative balances)The acquirer's credit riskASC 326 (CECL). Requires an expected-credit-loss estimate at origination — not on evidence of impairment. This is the record most often missed.
3Contingent and guarantee obligations — exposure to network or cardholder claims beyond any recorded receivableThe acquirer's contingent exposureASC 450-20-25-2 (probable + estimable), or ASC 460 where the arrangement is within guarantee scope.
The CECL point deserves emphasis. The statement that "no loss accrual is required absent evidence of impairment" is an incurred-loss idea and does not survive ASC 326. A receivable from a perfectly healthy merchant still carries an expected credit loss, however small, and it is recorded when the asset is recognized. Waiting for deterioration is exactly the behavior CECL was written to eliminate.
And collateral does not change whose money it is. Legally available merchant collateral reduces the measurement of the acquirer's expected loss on record 2 or 3. It does not convert merchant cash in record 1 into an acquirer loss reserve. Offsetting the two on the balance sheet requires a right of setoff under ASC 210-20-45-1 — verify it rather than assuming it.
ASC 450-20-25-2; ASC 326-20-15-2 and 30-2; ASC 460-10-15 and 25 (scope-dependent); ASC 405-20-40-1; ASC 210-20-45-1.

When a specific merchant exhibits loss indicators — elevated chargebacks, fraud alerts, bankruptcy filing, cessation of processing — the controller re-measures records 2 and 3 upward. The question is not whether an accrual is now "triggered," but whether the existing estimate still reflects expected loss given the new facts.

Net Loss Estimate (Specific Merchant)
Start with gross exposure:
  Sales still within the applicable dispute window × estimated dispute rate
  + any recorded receivable from the merchant

Less amounts legally available to absorb it:
  − Merchant collateral held and contractually applicable
  − Other supportable recovery (guarantees, insurance, setoff rights)

= Net expected loss to the acquirer

Record it under the standard that fits the exposure: ASC 326 for the
receivable, ASC 450 or ASC 460 for contingent obligations.

Count each dollar of collateral once. If reserve funds have already been
applied against a recorded obligation, that balance is spent and cannot be
deducted a second time here — see the roll-forward below.

Proactive Reserve Methodology for Systemic Events

A more complex scenario arises when a network rule change, regulatory event, or industry-wide disruption creates expected losses across a portfolio of merchants — not a single identified counterparty. In this case, a proactive reserve methodology may be appropriate under ASC 450's collective-basis provisions.

Critical Governance Note
Proactive or portfolio-level loss reserves represent a significant accounting estimate requiring CAO and technical accounting approval before initial booking. The methodology, probability assessment, loss estimation approach, and disclosure framework must be documented in a formal technical accounting memo. SOX documentation for the reserve estimate should include data inputs, model assumptions, sensitivity analysis, and management review procedures.

Controller Booking & Release Framework

EventDrCrASC Basis
Rolling reserve withheld from fundingMerchant PayableMerchant Reserve LiabilitySettlement mechanics
Reserve released to merchant per agreementMerchant Reserve LiabilityMerchant Payable / CashPerformance of refund obligation
Chargeback funded on merchant's behalf — step 1, record the obligationMerchant ReceivableCash / Settlement PayableASC 405-20 / settlement mechanics
Reserve applied to that obligation — step 2, apply collateralMerchant Reserve LiabilityMerchant ReceivableASC 405-20-40-1 (obligation discharged)
Expected credit loss on merchant receivableCredit Loss ExpenseAllowance for Credit LossesASC 326-20 — at origination, not on impairment
Contingent loss beyond any recorded receivableCB / Loss ExpenseLoss Contingency LiabilityASC 450-20-25-2 (or ASC 460 if in scope)
Contingency resolves favorablyLoss Contingency LiabilityReversal / IncomeASC 450-20-40-1

Journal Entries — Reserve Lifecycle

Reserve Roll-Forward — Complete Entry Sequence
One continuous sequence for a single merchant. Track the running reserve
balance in the right-hand column — it is what the final step depends on.


1 · Reserve withheld from funding ($1M volume, 10% rolling):
Dr Merchant Payable                $100,000
  Cr Merchant Reserve Liability      $100,000
                                     Reserve balance: $100,000

2 · Release after the 90-day hold:
Dr Merchant Reserve Liability      $95,000
  Cr Merchant Payable / Cash         $95,000
                                     Reserve balance: $5,000

3 · Chargeback funded on the merchant's behalf — two steps, not one.
First record what the merchant owes you; only then apply their collateral:
Dr Merchant Receivable             $5,000
  Cr Cash / Settlement Payable      $5,000  (network debits you)
Dr Merchant Reserve Liability      $5,000
  Cr Merchant Receivable              $5,000  (collateral applied)
                                     Reserve balance: $0

4 · Loss estimate on the remaining exposure. The collateral is now
exhausted, so nothing remains to deduct for it:
  Remaining gross exposure             $18,000
  Less reserve available                       $0  (spent in step 3)
  Less supportable recovery           ($5,000)
  = Net expected loss                  $13,000

Dr CB / Credit Loss Expense        $13,000
  Cr Allowance / Loss Liability      $13,000

Roll-forward proof: $100,000 opening − $95,000 released − $5,000 applied = $0 ✓
Two Errors This Sequence Is Built to Prevent
1 · Spending the same collateral twice. Deducting a $5,000 reserve in the loss calculation after that same $5,000 has already been applied to a chargeback understates the loss by its full amount — $8,000 booked where $13,000 was required. The defense is mechanical: carry a running reserve balance through the sequence and reconcile the ending balance to the merchant sub-ledger before computing any loss estimate. If the balance is zero, the deduction is zero.

2 · Crediting "Chargeback Recovery" out of nowhere. Applying reserve funds directly to a recovery income account recognizes income for money that was always the merchant's, and skips the obligation entirely. There is no recovery until there is first a recorded loss or receivable to recover against. Record the receivable and the cash outflow, then apply the collateral against it. If a recovery credit ever appears with no prior expense or receivable, the entry is wrong.
ASC 405-20-40-1; ASC 450-20-25-2; ASC 326-20-30-12.

Controller Checklist — Reserves

Reserve Close Controls
□ Reserve roll-forward reconciled: Opening + Withheld − Released − Applied = Closing
□ Every reserve balance tied to merchant sub-ledger
□ Reserve balance per merchant reconciled to sub-ledger before any loss estimate deducts it — collateral already applied is not available again
□ Coverage ratio calculated and compared to your documented internal floor (an escalation setting, not a network or GAAP threshold)
□ CECL allowance on merchant receivables measured — including for healthy merchants, at origination
□ ASC 450 / ASC 460 assessment run for contingent exposures beyond recorded receivables
□ Loss estimate documented with exposure calculation, collateral applied, and the standard relied on
□ Restricted vs. unrestricted reserve cash identified; restricted balances excluded from the float model and disclosed
□ Released reserves confirmed against holding period per MPA terms — no early release
□ Dynamic reserve triggers reviewed: any merchant with volume spike >50% MoM needs re-assessment
🔍 Controller Lens — Reserves & Risk
WHAT CREATES THE LIABILITY?Withholding from merchant settlement creates Merchant Reserve Liability. This is NOT revenue. It is a refundable deposit with a defined release schedule per the MPA.
SOURCE OF TRUTHReserve system sub-ledger by merchant. Each MID must have an individual balance. Aggregate GL balance = sum of all merchant sub-ledger balances. Any gap = reconciling item.
TIMINGLiability created at funding withheld; released per MPA terms. CECL allowance on merchant receivables runs from origination. ASC 450 / 460 accrual when a contingent loss beyond those receivables becomes probable and estimable.
KEY RISKReserve shortfall when merchant spikes chargebacks. Under-accrual on ASC 450 assessment. Reserve released too early. Sub-ledger not tied to GL — no audit trail.

Reserve Types — Decision Framework

Reserve TypeStructureWhen UsedRelease TriggerController Watch-Out
Rolling Reserve% of monthly GTV held for 90–180 days, then released as new deposits offsetStandard merchants with moderate CB historyAutomatic after holding period per MPAReconcile daily that roll is releasing correctly — over-holding is a merchant relations risk
Capped ReserveWithheld until a fixed dollar amount reached; no further withholding after capMerchants with predictable, bounded risk profileAfter holding period AND CB rate drops below thresholdCap amount must be reassessed when merchant volume grows significantly
Upfront ReserveLump sum deposited by merchant before processing beginsHigh-risk, seasonal, or new merchants with no track recordPost-program review (typically 6–12 months)Document receipt and determine the actual restrictions from the agreement and applicable law — segregation is not automatic. See the note below
Enhanced ReserveIncreased withholding triggered by risk event (CB spike, fraud alert, financial distress)Merchants showing deteriorating risk profileWhen risk indicators return to normal thresholdsRequires documented risk decision and merchant notification per MPA terms. Legal reviews process before triggering.
"Reserve" Does Not Tell You Whether the Cash Is Restricted
Two opposite assumptions circulate, and both are wrong as blanket statements: that reserve funds must always be segregated and can never be commingled, and that all held reserve cash is freely investable float. Neither follows from the label. Restriction is a question of fact with three inputs:

Contract — what the merchant agreement actually says about how the funds are held.
Law and regulation — safeguarding, money-transmission or deposit rules applicable to your entity and jurisdictions, which may or may not reach these balances.
Control — who can direct the cash, and whose name the account is in.

Get that answer before two things downstream depend on it. Cash presentation and disclosure: restricted balances are presented and disclosed separately, and restricted amounts are included with cash in the statement-of-cash-flows totals with the nature of the restriction disclosed (ASC 230-10-50-7). The float model: Chapter 15's FTP and float economics assume an investable balance. Feeding restricted reserve cash into that model overstates float income and, if it has driven pricing or FTP credits, the error compounds. Reconcile the reserve balances used in the float model to the balances you have concluded are genuinely available.
ASC 230-10-50-7; ASC 210-20-45-1; ASC 405-20-40-1. Actual restrictions require the relevant agreement and applicable law.

Dynamic Reserve Triggers — What Forces Action

TriggerThresholdController ActionTimeline
Merchant approaching network monitoring thresholdVisa: VAMP — see the note below. Mastercard: ECP (ECM/HECM). Use the current published parameters, not legacy figuresIncrease reserve assessment; alert risk teamSame week
Coverage ratio falls below floorInternal setting — e.g. <0.80x (reserve / exposure). Not a network or accounting thresholdRe-measure expected loss under the applicable standard; consider enhanced reserveSame month
Merchant volume spikes sharply MoMInternal setting — e.g. GTV doubles in 30 daysRe-underwrite; reassess reserve %Same week
Merchant files bankruptcy / goes darkAny insolvency indicatorFreeze reserve, halt funding, run full ASC 450 assessmentSame day
Seasonal merchant approaching end of season90 days before season endEvaluate extended hold period; model post-season CB exposureProactive — 3 months out
VDMP and VFMP Are Retired — Use VAMP
Reserve triggers built on the old Visa Dispute Monitoring Program and Fraud Monitoring Program thresholds are monitoring a program that no longer operates. Visa consolidated them into the Visa Acquirer Monitoring Program (VAMP), and VAMP is constructed differently enough that a threshold cannot simply be carried across:

It is a count ratio, not a value ratio. VAMP measures TC40 fraud plus TC15 dispute counts against settled CNP transaction counts (TC05), subject to defined exclusions. A reserve model that computes a dollar-based dispute rate is not measuring the thing the network measures.
Thresholds are dated and differ by scope. Where the fact sheet's acquirer-eligibility condition is met, the excessive-merchant threshold is 150 bps effective 1 April 2026 alongside a minimum monthly fraud-and-dispute count, for AP, Canada, EU and U.S. Acquirer-level thresholds and other regions differ.
Legacy fine schedules should not be modeled. Old per-dispute and tiered fine tables are not substantiated as current; obtain the applicable fee schedule rather than accruing from a remembered number.

On the Mastercard side, use the Excessive Chargeback Program (ECM and HECM categories) and, separately, the fraud monitoring program where applicable. Note the ratio construction differs from Visa's: ECP compares current-month chargebacks to prior-month transactions, so a same-month ratio will not reproduce it. The current merchant rulebook refers precise thresholds and assessments to Mastercard's monitoring and pricing resources — take them from there.

Also keep network thresholds and accounting triggers distinct. Crossing a monitoring threshold is a commercial and risk event that may inform your loss estimate. It does not by itself establish that a loss is probable and estimable under ASC 450, nor does it set a CECL measurement. Internal settings such as an 0.80x coverage floor are escalation tools you have chosen — label them as such so no one mistakes them for authoritative requirements.
Visa VAMP fact sheet (including the 1 April 2026 threshold); Visa Core Rules §10.4.3.1; Mastercard Security Rules and Procedures — Merchant Edition §8.3.
Failure Scenario — Merchant Insolvency After Holiday Season
What happens: A direct-to-consumer retailer processes $8M in December on 90-day rolling reserve at 10% ($800K held). In January, they go bankrupt. Chargebacks begin arriving in February — consumers disputing goods not delivered. By March, CBs total $1.2M. Reserve covers $800K. Incremental loss = $400K.
P&L impact: $400K unbudgeted expense. ASC 450 accrual should have been triggered the moment bankruptcy was filed — not when CBs hit. If controller waited for actual CB volume, accrual is 60 days late.
Control: Monitor merchant news and public filings weekly for top-50 merchants. Any insolvency indicator triggers same-day ASC 450 assessment at full theoretical exposure.
Chapter 06

FX &
Cross-Border

Cross-border transaction mechanics, FX exposure types, DCC economics, hedging vs. pass-through decisions, and the controller's framework under ASC 815 and ASC 830.

Cross-border transactions — those where the card is issued in a different country than the merchant location — introduce FX exposure on multiple dimensions: the settlement currency, the currency of the merchant's DDA, and the currencies in which the acquirer operates. For a globally active acquirer with multi-currency merchant portfolios, FX exposure in payments is material and requires a deliberate accounting and risk management framework.

Cross-Border Transaction Mechanics

When a UK cardholder uses a Visa card at a US merchant, the transaction is denominated in USD but originates from a GBP-issued card. The issuer settles in USD with the network, and the acquirer receives USD settlement. If the merchant's DDA is USD-denominated, the acquirer has no FX conversion of its own on that transaction. The cardholder-side conversion happens at the issuer, which converts USD to GBP to bill its customer.

Two Different Charges, Often Confused
A cross-border transaction generates charges on both sides of the model, and they are frequently merged into one line in controller documentation. They are unrelated:

The issuer's foreign transaction fee is charged by the issuer to its own cardholder, on the cardholder's statement. It is the issuer's revenue. The acquirer never sees it, cannot influence it, and has no accounting for it whatsoever.
The network's International Service Assessment is charged by the network to the acquiring side on qualifying cross-border volume. It is the acquirer's cost, and it is the one that appears in the scheme-fee accrual and may be passed through to the merchant.

Treating them as the same fee produces a cross-border cost model that reconciles to neither the network invoice nor the merchant's statement. When documenting cross-border economics, state which side of the four-party model each charge sits on.

The picture changes materially when the acquirer operates across currencies — processing merchants in EUR, GBP, JPY — or offers Dynamic Currency Conversion (DCC).

Type 1: Acquirer Multi-Currency Settlement

Acquirer processes merchants in local currency and receives settlement in that currency. Acquirer bears the exposure between transaction date and the date it converts those receipts to its functional currency. This is a transactional FX exposure under ASC 830.

Type 2: Dynamic Currency Conversion (DCC)

Acquirer (or its DCC processor) offers the foreign cardholder the option to pay in their home currency at the point of sale. The acquirer earns a DCC margin (the spread between the network rate and the rate quoted to the cardholder). This is revenue, not FX translation — and it's often the highest-margin product in the cross-border portfolio.

Type 3: Network ISA Pass-Through

The acquirer passes the network's International Service Assessment (ISA) to the merchant as a fee. This is a pure cost pass-through — no FX exposure on the acquirer's books, but significant pricing and disclosure considerations in merchant agreements.

Type 4: Functional Currency Translation

Acquirer subsidiaries operating in non-USD functional currencies require CTA (Cumulative Translation Adjustment) accounting under ASC 830. The controller must identify functional currencies for each legal entity and map balance sheet exposures to the appropriate translation methodology.

ASC 830 — Foreign Currency Translation

ASC 830 (Foreign Currency Matters) governs two distinct situations: remeasurement (when a transaction is denominated in a currency other than the entity's functional currency) and translation (when a foreign subsidiary's financial statements are converted to the parent's reporting currency).

Remeasurement vs. Translation — Key Distinction
Remeasurement: Monetary items (settlement receivables, merchant payables denominated in foreign currency) are remeasured at the balance sheet rate. FX gains/losses flow through income. This is the most common scenario for acquirer FX exposure on in-flight settlement.

Translation: Foreign subsidiary assets, liabilities, income, and expenses translated at appropriate rates (current/average). Resulting CTA recorded in OCI, not income, until disposal of the entity.

ASC 815 — Hedging Framework

Acquirers with material FX exposures may elect to hedge using forward contracts, FX swaps, or options. ASC 815 governs whether hedge accounting is available and how to document, assess, and report hedges. The decision to hedge (vs. accept FX P&L volatility vs. pass through to merchants) is a joint risk management and accounting decision with significant P&L implications.

Hedge TypeASC 815 DesignationGain/Loss RecordingApplicable to Acquiring
Fair Value HedgeFair value hedge of firm commitmentBoth hedged item and derivative in income; should offsetLess common in acquiring (few firm commitments)
Cash Flow HedgeHedge of variability in future cash flowsEffective portion in OCI; reclassified to income when hedged item affects incomeCommon for expected future cross-border settlement receipts
Net Investment HedgeHedge of FX risk in foreign subsidiaryEffective portion in OCI (CTA); matches translation gain/lossUsed for EUR/GBP subsidiary investments
Economic Hedge (no designation)NoneMark-to-market through income; no hedge accounting offsetUsed when documentation/effectiveness testing not maintained

DCC Revenue Recognition and FX Margin Accounting

DCC revenue is the margin between the wholesale rate used to source the merchant's currency and the rate quoted to the cardholder. Before booking it, answer three questions in order — the answers are not the same at every acquirer, and none of them can be assumed.

Three Questions Before You Book DCC Revenue
1 · Who actually provides the conversion service? Many acquirers do not run DCC themselves — a third-party DCC provider sets the rate, bears the FX position and pays the acquirer a commission or revenue share. If that is your arrangement, the acquirer's revenue is the commission, and gross presentation of the full spread reports revenue the entity never earned. Where the acquirer sets the rate and carries the position, a principal conclusion may well follow. Read the DCC agreement before concluding.

2 · Gross or net follows from control, not from earning a spread. Apply the same per-service control analysis used in Chapter 3. Earning a margin is not evidence of principal status; it is simply how the arrangement is priced.

3 · When is the service performed? The conversion service is delivered when the transaction is converted at the quoted rate, which is generally at the point of sale — not automatically at cash settlement days later. Identify the performance obligation and recognize accordingly; settlement timing is a cash event.

Keep two things separate afterwards. The DCC margin is revenue for a service. Any subsequent movement on the resulting monetary items — an FX-denominated receivable or payable outstanding at period end — is a remeasurement gain or loss under ASC 830-20-35-1, not more or less DCC revenue. Merging them makes the product's true margin unreadable.
ASC 606-10-55-36 through 55-39A; ASC 606-10-25-23 through 25-30; ASC 830-20-35-1.

Whatever the conclusion, present DCC separately from interchange and MDR revenue in management reporting — it has a different driver, a different margin profile and a different regulatory exposure.

DCC Revenue Calculation
Merchant is owed: €100   (the sale is in EUR; the cardholder pays in USD)

Wholesale cost to buy €100    1.0820 USD/EUR → $108.20 out
Rate quoted to cardholder     1.1090 USD/EUR → $110.90 in

DCC margin: $110.90 − $108.20 = $2.70 per transaction

Two different percentages — say which one you mean:
  Margin on amount charged:  2.70 / 110.90 = 2.43%
  Mark-up over wholesale cost: 2.70 / 108.20 = 2.50%
Check the Direction Before Checking the Arithmetic
A DCC margin exists only when the cardholder is charged more than the wholesale cost of buying the merchant's currency. Quoting the cardholder a rate below wholesale — 1.0550 against a 1.0820 cost — means collecting $105.50 to settle a $108.20 obligation. That is a $2.70 loss per transaction, and labeling it a margin does not change the direction of the cash.

The error is easy to make because subtracting the smaller number from the larger yields $2.70 either way. Two habits prevent it:

Anchor on the obligation. Start from what the merchant is owed in their currency, price what it costs you to deliver it, then compare to what you collected. Margin = collected − cost, in that order, signed.
Write the quote convention on the page. At 1.0820 USD/EUR, a higher number means EUR costs more USD. A cardholder-favourable rate is therefore a lower number — and a lower number is a loss to you. Inverted quote conventions (EUR/USD vs USD/EUR) are where most of these errors originate; state which one the figure uses every time.
ASC 830-20-25-1. Cardholder disclosure and rate-setting requirements: Mastercard DCC Guide; Visa Core Rules §5.9.
Regulatory Risk
DCC has attracted regulatory scrutiny globally (EU Payment Services Directive, card scheme rules) due to concerns about cardholder disclosure. Acquirers must ensure DCC offerings comply with network mandatory disclosure rules and applicable regulations, as non-compliance can result in scheme fines and reputational risk — both of which have P&L implications that the controller's reserve framework should address.

Journal Entries — FX Remeasurement

Month-End FX Remeasurement — Settlement Receivable
EUR-denominated settlement receivable booked at transaction rate:
Dr Settlement Receivable (EUR)    $1,082,000  (€1M at 1.0820)
  Cr Settlement Cash / Payable        $1,082,000

Period-end remeasurement (rate moves to 1.0650 — USD strengthened):
Dr FX Loss — P&L                    $17,000  (€1M × (1.0820−1.0650))
  Cr Settlement Receivable (EUR)    $17,000

If rate moves favorably (1.0820 → 1.0950):
Dr Settlement Receivable (EUR)    $13,000
  Cr FX Gain — P&L                    $13,000

Critical: FX gains/losses on monetary items go through P&L (ASC 830-20).
Translation of foreign subsidiary net assets goes through OCI (ASC 830-30).

FX Controls Framework

ControlFrequencyOwnerFailure Risk
Remeasure all FX-denominated monetary items at period-end rateMonthlyControllerMisstated receivables and payables
Source FX rates from treasury/central bank; document rate sourceMonthlyController/TreasuryUnsupported rates = audit finding
Reconcile DCC margin to FX rate differential by transaction batchMonthlyControllerDCC revenue leakage undetected
Assess hedge effectiveness using the documented methodQuarterlyController/TreasuryFailing to qualify ends hedge accounting prospectively; AOCI is evaluated separately, not auto-released
Confirm functional currency determination for each legal entityAnnualController/CAOWrong functional currency = systematic misstatement
Test CTA balance for foreign subsidiariesMonthlyControllerCTA error compounds each period

Controller Checklist — FX & Cross-Border

FX Close Controls
□ All FX-denominated receivables and payables remeasured at balance-sheet-date rate
□ FX rate source documented (treasury system, central bank, or Bloomberg mid-rate)
□ FX gain/loss on P&L — not OCI — for monetary item remeasurement
□ CTA roll-forward reconciled for each foreign subsidiary
□ DCC margin calculated and recognized separately from FX translation gains/losses
□ Any hedge designated under ASC 815 — effectiveness assessed using the method documented at inception
□ If a hedge ceases to qualify, discontinuation applied prospectively and the AOCI balance evaluated under the applicable guidance (not automatically released in full)
Two Hedge-Accounting Shortcuts That Do Not Hold
"80–125% is the ASC threshold." It is not. It is a widely used quantitative convention — a dollar-offset band that many entities adopt — not a bright line written into the standard as the universal test of effectiveness. The standard requires you to select and document a permissible method of assessing effectiveness at hedge inception and apply it consistently. Depending on the relationship, that may be a qualitative assessment, a quantitative one, or a method supported by the current guidance's simplifications. Citing "the 80–125% rule" as though it were the requirement signals the assessment method was never actually documented — which is itself the finding.

"Dedesignation sends all historical mark-to-market to P&L." Also not right, and it is the more expensive error. Discontinuing hedge accounting generally changes the accounting prospectively: the derivative continues at fair value through earnings from that point. For a cash flow hedge, amounts already accumulated in AOCI are not automatically reclassified to income simply because the hedge ceased to qualify. They generally remain in AOCI and are reclassified when the forecasted transaction affects earnings — unless that transaction is no longer probable of occurring, which is a separate determination with its own consequences.

Control: document the effectiveness method and the discontinuation analysis at the same time as the designation memo, not when a hedge first fails. A discontinuation policy written under pressure is how AOCI gets emptied into earnings a period early.
ASC 815-20-25-75 through 25-80; ASC 815-30-40-1 through 40-6; FASB ASU 2017-12.
Failure Scenario — Functional Currency Misidentification
What happens: A UK acquiring subsidiary operates primarily in GBP but intercompany loans and management fees are denominated in USD. If the controller incorrectly designates USD as the functional currency (because executive management is US-based), all GBP revenues and expenses will be remeasured through P&L rather than translated through OCI — creating artificial P&L volatility that has no economic substance.
Audit risk: ASC 830-10-55 indicators must be documented. Primary economic environment (where cash flows are generated) controls the determination. If wrong, every period's P&L and OCI has been misstated.
🔍 Controller Lens — FX & Cross-Border
WHAT CREATES THE EXPOSURE?Any monetary asset or liability denominated in a currency other than the entity's functional currency. Settlement receivables in EUR, GBP, JPY are the most common in acquiring.
SOURCE OF TRUTHPeriod-end spot rate from treasury or central bank (document the source). FX gain/loss flows through P&L. Translation of foreign subs flows through OCI. Never mix the two.
TIMINGRemeasure ALL FX-denominated monetary items at balance-sheet date. No exceptions. Even small balances left unremeasured create cumulative errors that compound each period.
KEY RISKFunctional currency wrong (OCI should be P&L or vice versa). DCC margin not stripped from FX translation. Hedge designated but effectiveness testing not maintained → dedesignation risk.
Chapter 07

Reconciliation
& Close

Settlement file vs. GL reconciliation, scheme billing rec, chargeback reserve rec, and a practical monthly close calendar for the acquiring controller.

Reconciliation in payments is a multi-layered matching exercise: settlement data flowing from the network must tie to internal processing records, which must tie to the GL, which must tie to the bank statement. Each layer introduces potential breaks that, if unresolved, compound across periods. A disciplined close process in acquiring requires dedicated settlement reconciliation tooling — whether a purpose-built system or a well-structured Excel framework built specifically around the daily settlement file format — and a controller who understands the source data well enough to know whether a break is a timing difference, a booking error, or a genuine exposure.

The Four Layers of Acquiring Reconciliation

Reconciliation Hierarchy — Acquiring Controller Framework
LAYER 1 · NETWORK SETTLEMENT FILES Network clearing files · Transaction-level detail per MID LAYER 2 · INTERNAL PROCESSING SYSTEM Authorized / Cleared / Settled transactions · Merchant-level P&L attribution LAYER 3 · GENERAL LEDGER Subledger to GL reconciliation · Revenue, payables, reserves, scheme fees LAYER 4 · BANK / SETTLEMENT ACCOUNT Bank statement tie-out · Fed settlement account · Nostro reconciliation ✗ ✗ ✓

Settlement File Reconciliation

The daily reconciliation starts with what the networks send you. In practice that is not one file but several, and the distinction matters more than the file names: clearing data carries transaction-level detail, settlement reporting carries the net funds position, and billing feeds carry fees. The controller's team must reconcile this data against:

Do Not Name a Single File as "The" Settlement File
It is common to see "the Visa TC46" described as the one file containing transaction detail, interchange, scheme fees and the net settlement position. Treat that as a claim to verify against your own implementation, not a fact — and note that it merges three different things:

Clearing data — transaction-level records supporting revenue recognition and interchange.
Settlement reporting — the net funds position per settlement cycle, which is what you tie to the bank statement.
Billing feeds — fee detail, delivered on the billing cycle, which is what you tie the scheme-fee accrual to.

The network rules themselves keep clearing and settlement as separate processes. Expecting one file to reconcile all three is how a Layer 1 break gets misdiagnosed for a day: the team compares a settlement summary to transaction counts, finds they do not agree, and investigates a difference that was never supposed to be zero.

Control: maintain an interface inventory naming each feed you actually receive, the network technical specification version it conforms to, its cadence, and which reconciliation layer consumes it. Take exact record and file identifiers from your current network technical specifications and your processor's interface documentation — they differ by processor, region and connection, and a code that is right for one implementation is wrong for another.
Clearing and settlement as distinct processes: Visa Core Rules §1.7; Mastercard Transaction Processing Rules.

Monthly Close Calendar

DayClose ActivityOwnerKey Data Source
M+1Last business day settlement rec complete; open items flaggedSettlement TeamNetwork clearing/settlement files; Bank Statement
M+2Revenue accrual for late-clearing transactions; preliminary revenue flashControllerProcessing System; Revenue Subledger
M+3Scheme fee accrual (if billing not yet received); interchange cost true-upControllerPrior month MCBS/CBS; volume report
M+4Reserve balance reconciliation; specific reserve review; CB reserve adequacyController / RiskReserve System; CB Aging Report
M+5FX remeasurement; cross-border revenue true-up; DCC margin recognitionController / TreasuryFX rates; cross-border volume file
M+6GL subledger tie-out; inter-company eliminations; management P&L reviewControllerGL System; Subledger Reports
M+7–8Variance analysis vs. budget and prior month; executive reportingController / FP&AGL; Prior period comparatives
M+10Scheme billing statement receipt; final scheme fee true-up; adjust accrualControllerVisa CBS; Mastercard MCBS
Scheme Billing Timing Gap
Visa and Mastercard billing statements are typically received 15–30 days after month-end. Controllers must accrue scheme fees based on volume estimates and true up when statements are received. Persistent accrual variances are often due to FANF tier changes, new fee categories, or volume-tier resets that weren't reflected in the accrual model. A quarterly accrual model review is best practice.

Journal Entries — Close Process Entries

End-to-End Close Journal — Monthly Settlement Cycle
M+1 (cutoff — transactions cleared in period, not yet settled):
$3,000,000 of last-two-days clearing. Scenario A rates: MDR 1.75%,
interchange 1.40%, scheme 0.13%, both fees withheld in settlement.


Dr Settlement Receivable           $2,954,100  ($3.0M − IC $42,000 − scheme $3,900)
Dr Interchange Expense              $42,000
Dr Scheme Fee Expense               $3,900
  Cr Merchant Payable               $2,947,500  ($3.0M − MDR $52,500)
  Cr MDR Revenue                     $52,500
Dr = $3,000,000 · Cr = $3,000,000 ✓ · margin $6,600 (22 bps)

M+3 (scheme fee accrual):
Dr Scheme Fee Expense             $130,000
  Cr Scheme Fee Accrual Payable     $130,000

M+10 (billing true-up — CBS received, actual $127,400):
Dr Scheme Fee Accrual Payable     $2,600
  Cr Scheme Fee Expense             $2,600  (reversal of over-accrual)
A Cutoff Entry That Balances Can Still Be Wrong
The most dangerous version of this entry credits interchange — Cr IC Cost Accrual $42,000 — and plugs a merchant payable to make the columns agree. It does agree, because two errors offset. But interchange is a cost the acquirer incurs, so it belongs on the debit side; crediting it understates cost of revenue and, once the plug is included, misstates the merchant payable as well.

Two checks catch it before it reaches the ledger:

Every cutoff entry should total GTV. The transaction is $3,000,000 of volume, so both columns should foot to $3,000,000 — not to the net settlement figure. If your columns tie at $2,940,000, a leg is missing or mis-signed.
Derive both sides independently. The receivable is GTV less fees withheld; the merchant payable is GTV less MDR. Compute each from GTV, then check that they differ by exactly the recognized margin ($2,954,100 − $2,947,500 = $6,600). A payable that had to be plugged will fail this test.

And confirm the population is genuinely unposted. A cutoff accrual is for transactions cleared in the period that the sub-ledger has not yet recorded. If those transactions have already posted through the normal clearing process, adding this entry double-counts revenue, cost and the payable. Reconcile the accrual population to the sub-ledger before booking, and reverse it in the following period against the actual postings.
ASC 606-10-32-2 and 45-4; ASC 250-10 (error correction) if a prior period was affected.
Failure Scenario — Missing Cutoff Creates Revenue in Wrong Period
What happens: The controller uses settlement date rather than clearing date as the revenue trigger. The month ends on a Friday. The Thursday and Friday clearing files — both within the period — do not settle until the following Monday and Tuesday. Because the trigger is settlement, that $6,000,000 of in-period clearing posts to the next period instead.
Impact: Current period understated by $105,000 of MDR revenue ($6M × 1.75%), with cost and merchant payable displaced alongside it; next period overstated by the same amounts. If material, this is an error in previously issued statements requiring a memo and possible restatement — not a timing preference.
Control: Lock the cleared-transaction population as at the last calendar day of the period and recognize every transaction in it, whatever its settlement date.

Two traps in how this scenario is usually told.

Pick dates that are actually inside the period. A scenario where the month ends Wednesday and the displaced volume is Thursday's and Friday's clearing describes activity that belongs in the next month regardless of policy — there is no cutoff error to illustrate, because nothing was misallocated. The error only exists when in-period clearing is pushed out by a settlement-date trigger. Getting this wrong in a training example teaches the opposite of the control.
A file arriving late does not change when the service was performed. Re-requesting a clearing file, or receiving a replacement copy, does not move the underlying clearing date. Keep event date (when the transaction cleared, which drives recognition) and receipt date (when you got the file, which drives your operational SLA) as separate fields. Conflating them lets a transmission problem quietly become a recognition problem — and invites the temptation to treat a re-delivered file as in-period simply because it arrived before the books closed.
ASC 606-10-25-23; ASC 250-10-20 (error in previously issued financial statements).

Controller Checklist — Reconciliation & Close

Reconciliation Close Controls
□ Revenue cutoff = clearing date — locked from processing system clearing file
□ Settlement receivable aging: every open item >3 days flagged and explained
□ Scheme fee accrual covers all categories: assessment, NABU, APF, FANF, ISA, quarterly fees
□ GL subledger tie-out: every balance sheet account has supporting detail
□ Interchange cost per GL matches network settlement file total for the period
□ Reserve roll-forward balanced and tied to merchant sub-ledger
□ Management variance bridge completed: volume effect + rate effect + mix effect = total variance
□ All open items from prior month's reconciliation closed or escalated
🔍 Controller Lens — Settlement Reconciliation
WHAT ARE YOU RECONCILING?Network file → Processing system → GL subledger → Bank statement. Four layers. A break at any layer means the books are wrong. Find it before your auditor does.
SOURCE OF TRUTHThe network clearing file is the primary document. Bank statement confirms cash. Anything in your GL that can't be traced to a network file line item is unsupported.
TIMINGDaily: settlement tie-out. Monthly M+1: cutoff lock. Monthly M+10: scheme billing true-up. Quarterly Q+45: quarterly fee true-up. Every break has a deadline for resolution.
KEY RISKSettlement receivable open >3 days = escalate. Scheme fee accrual based on wrong volume base. Cutoff error (settlement date used instead of clearing date). GL account with no sub-ledger.

Four-Layer Reconciliation — Break Escalation Framework

Every settlement break lives at one of four layers. The controller's job is to identify which layer the break is at before doing anything else. Fixing the wrong layer wastes hours and leaves the real break open.

LayerWhat You're ComparingExpected ResultIf It Doesn't TieEscalation
1. Network → ProcessingNetwork clearing file transaction count and volume vs. internal processing systemExact match on count and volumeMissing transactions: check for late arrivals, rejected items, or file transmission failures. Amount discrepancy: check for tip adjustments, incremental auths not captured in base file.Operations team same day. If >$50K or >1% of volume: network relations escalation.
2. Processing → GL SubledgerProcessing system cleared volume and revenue vs. GL revenue subledgerRevenue subledger = cleared volume × MDR rate for each merchantRate mismatch: MDR applied incorrectly in billing system. Missing transactions: cutoff lag — transactions cleared but not yet posted. Timing: batch posting delay.Finance operations + billing system team. Investigate before period closes.
3. GL Subledger → GL BalanceSum of all subledger lines vs. GL account balanceSum of subledger = GL balance to the pennyOrphaned entries: GL posting without subledger line (manual entry error). Missing subledger lines: automated posting failed. Rounding: check for aggregation vs. individual posting approach.Controller escalation — no GL account should ever have a balance not supported by subledger. Zero tolerance.
4. GL Balance → Bank StatementCash / Settlement Account GL balance vs. bank statement receiptsGL cash receipt = bank statement deposit for each settlement dateTiming: settlement received but not yet posted in GL. Missing bank receipt: network payment delayed. Excess bank receipt: duplicate settlement (rare but happens). FX: if multi-currency, remeasurement difference.Treasury same day if >$100K. If bank receipt missing >3 business days: network relations urgent escalation.

Open Item Aging — Hard Rules

Break AgeAction RequiredOwnerEscalation Level
Day 1Document break, identify layer, begin investigationController analystNone — normal workflow
Day 2Root cause identified, remediation plan in placeControllerNotify Manager if >$50K
Day 3Break must be resolved OR formally escalated with documentationControllerController → VP Finance
Day 5+Formal escalation regardless of amount. Consider accrual entry if break may represent an unrecorded liability.Controller + VP FinanceCFO awareness. Network relations if Layer 1/4 break.
Month-endAny open item must be documented, explained, and approved before close certificationControllerCAO sign-off required for any open item >$25K at close

What a Real Break Looks Like — Three Scenarios

Failure Scenario 1 — Layer 1 Break: Missing Clearing File
What happens: Processor's SFTP delivery of the Visa clearing file fails silently on the last business day of the month. No error notification. The controller runs the Layer 1 check and finds 47,000 transactions in the network portal that don't appear in the processing system. GTV gap: $4.7M. This is not a revenue question yet — it's a file transmission question. But if not caught by 5pm, month-end revenue is understated by $82,250 (MDR on $4.7M).
Resolution: Re-request file from processor. Post to processing system. Revenue and IC expense both book in current period if clearing date is in-period. If next-day re-delivery pushes clearing date into the next period: true cutoff decision — document with CAO.
Failure Scenario 2 — Layer 3 Break: Manual Journal Without Subledger
What happens: A finance analyst posts a manual adjusting entry to the MDR Revenue GL account to correct a prior-month error. The entry hits the GL but there is no corresponding subledger line. The GL-to-subledger tie-out fails. Now the subledger says $1,748,500 and the GL says $1,750,000. The $1,500 difference has no audit trail.
Resolution: Every manual entry to a revenue or balance sheet account requires a subledger line created simultaneously. No exceptions. SOX control: all manual GL entries to revenue accounts require controller approval and subledger documentation.
Chapter 08

Chargebacks
& Disputes

Full chargeback lifecycle, representment mechanics, reason code taxonomy, P&L flow-through, and reserve implications for the acquiring controller.

Chargebacks are the mechanism by which cardholders dispute transactions and reverse funds previously settled to merchants. For the acquirer, chargebacks create an immediate financial obligation — the acquirer is required by network rules to return funds to the issuer upon receipt of a valid chargeback, with subsequent recovery from the merchant or from reserves. Chargeback management is simultaneously a risk management, operational, and accounting function, and the controller must understand all three dimensions.

The Chargeback Lifecycle

Chargeback Flow — From Dispute to Resolution
CARDHOLDER Dispute Filed Day 0 ISSUER CB Initiated D+5 to D+120 NETWORK CB Processed T+2 of CB Date ACQUIRER CB Received Debit from network Acquirer reviews & notifies merchant → merchant decision MERCHANT DECISION Accept CB or Representment? ACCEPT CB Deduct from merchant / reserve GL: Dr Payable / Cr Cash REPRESENTMENT Evidence to network / issuer Response window per network rules WIN CB reversed → credit back LOSE / ARB Pre-arb or network arb Controller impact: GL entries at each stage · Reserve draw-down · P&L loss on net unrecovered CBs · Scheme CB fees

Visa Chargeback Reason Code Framework

Validate Every Row Against the Current Rules
Reason codes and their clocks are operational parameters that drive real deadlines, and they change. Two specific cautions before using the table below:

Code-to-description mappings are easy to transpose. Within the 13.x consumer-dispute family the descriptions are adjacent in meaning and frequently swapped in secondary sources — 13.2 is Cancelled Recurring Transaction while 13.7 is Cancelled Merchandise/Services. Routing a dispute on the wrong code sends the wrong evidence to the wrong workflow and can forfeit the response.
A single "120 days" does not describe the family. Time limits run from different start events by condition — transaction date, expected delivery or service date, the date services were cancelled, or the date the cardholder became aware — and several conditions carry different maximums and regional exceptions. The start event matters as much as the count.

Control: maintain the code table as dated reference data sourced to the current dispute rules, with the clock start event recorded per condition, and re-verify on each rules release. Treat the table below as a structural illustration, not as configuration.
Visa Core Rules §§11.10.3 and 11.10.8 (dispute conditions and time limits).
CategoryVisa CodeDescriptionTime Limit (verify)
Fraud10.4Card-absent fraud (CNP)120 days from transaction
Fraud10.5Visa Fraud Monitoring Program120 days
Authorization11.1Card Recovery Bulletin75 days
Authorization11.3No Authorization75 days
Processing Error12.6Duplicate Processing120 days
Consumer Dispute13.1Merchandise / Service Not Received120 days from expected delivery
Consumer Dispute13.3Not as Described / Defective120 days from transaction
Consumer Dispute13.6Credit Not Processed120 days from credit expected date
Consumer Dispute13.2Cancelled Recurring TransactionCondition-specific — verify
Consumer Dispute13.7Cancelled Merchandise / ServicesCondition-specific — verify

P&L Flow-Through and Reserve Implications

The P&L impact of chargebacks depends on whether the chargeback can be recovered from the merchant. For financially sound merchants with sufficient reserve or DDA balance, chargebacks are typically a pass-through — the acquirer debits the merchant, the net P&L impact is zero (offset by reserve draw-down or direct merchant debit). The P&L exposure materializes when:

P&L Loss Triggers
(1) Merchant insolvency — no DDA balance, reserve insufficient to cover CB liability;
(2) Reserve deficiency — CB exceeds reserve balance and merchant cannot fund the shortfall;
(3) Network CB fees — scheme per-CB fees ($15–$25/CB for Visa, higher for excessive CB rates) are a direct P&L cost;
(4) Network monitoring programs — Visa VAMP and Mastercard ECP (the former VDMP/VFMP and EDRM names are retired): merchants breaching the applicable thresholds trigger assessments charged to the acquirer and often passed to the merchant. Take thresholds and amounts from the current published program materials rather than legacy fee tables — see Chapter 5 and Chapter 14.
Net CB Loss (Specific Merchant Failure)
Gross CB Liability = Open CB Count × Average Transaction Amount
Reserve Available = Current Reserve Balance
Merchant DDA Available = Current DDA Balance
Net Loss = Gross CB Liability − Reserve − DDA − Other Recovery
= Unrecovered Loss → ASC 450 Accrual Required if Probable + Estimable

Concessions vs. Errors vs. Disputes — Critical Distinction

These three categories look similar operationally but have completely different accounting treatments. Conflating them is a recurring audit finding in payments finance.

CategoryDefinitionAccounting TreatmentP&L Line
ConcessionAcquirer waives a fee or grants a credit to retain a merchant relationshipVariable consideration (ASC 606-10-32-6 through 32-14). Estimate expected concessions as they arise — recognition is not deferred until the concession is formally granted — and update the estimate each periodReduces MDR revenue
ErrorProcessing error causes incorrect billing to the merchant (wrong rate, duplicate charge)Revenue correction; if a prior period is affected and material, evaluate under ASC 250Revenue correction — not an expense
DisputeCardholder disputes a transaction; issuer initiates a chargeback against the acquirerNot a single answer — see the three-part breakdown below. A network debit you have actually been assessed is a recorded obligation, not a contingencyDepends on the component
A Chargeback Is Three Records, Not One Contingency
The instinct to treat an open dispute as a loss contingency "disclosed only until resolved" defers a liability that already exists. When the network debits you, the money is gone — whatever the dispute's eventual outcome. Decompose it:
ComponentWhen recordedStandard
Settlement obligation / cash outflow — the network debit you have been assessedWhen assessed, not when the dispute concludesRecorded liability or cash movement. Not ASC 450 — there is nothing contingent about a debit already taken
Merchant receivable — the amount recoverable from the merchantWhen the obligation arises, to the extent recovery is supportableASC 326 — measure an expected credit loss allowance on it from recognition
Residual exposure — expected loss beyond recorded receivables, including disputes not yet filedWhen probable and estimableASC 450-20-25-2, or ASC 460 where in scope
The practical failure is deferring the first record while the dispute is "still open." That understates liabilities and overstates cash-generating capacity, and it is precisely the population an auditor samples. Record the debit when assessed; assess recoverability separately; reserve the residual under its own model. Resolution of the dispute later adjusts the receivable and the allowance — it does not retroactively determine whether the debit occurred.
ASC 405-20-40-1; ASC 450-20-25-2; ASC 326-20-15-2 and 30-2; ASC 460-10-15 and 25 (scope-dependent).
Do Not Apply a Count Ratio to Dollar Volume
Dispute-rate metrics are typically count-based — disputes divided by transactions — because that is how the networks construct their monitoring programs. Exposure is value-based. Multiplying a count ratio by GTV silently assumes the average disputed ticket equals the average transaction ticket, which is almost never true: disputed transactions skew toward higher-value, card-not-present and delayed-delivery items.

Convert properly: expected dispute dollars = expected dispute count × the average disputed ticket drawn from your own dispute history — not the portfolio average ticket. Where the disputed-ticket distribution is materially skewed, model by band rather than on a single mean. If you must use a value-based rate, derive it from disputed dollars over total dollars directly, and keep it clearly separate from the count-based ratio used for network monitoring. Mixing the two is how a reserve model and a compliance dashboard end up disagreeing about the same portfolio.
ASC 450-20-25-2; ASC 326-20-30-2.
Audit Risk — Misclassifying Concessions as Errors
A common pattern: the operations team issues merchant credits labeled as "billing corrections" when they are actually relationship concessions. Result: credits are booked as revenue reversals (correct for errors) rather than as variable consideration adjustments (correct for concessions). The income statement treatment may be similar but the disclosure, controls, and revenue recognition methodology are different. Auditors will trace credit memos to supporting documentation. "Billing correction" with no underlying billing error = audit finding.

Controller Checklist — Chargebacks & Disputes

Chargeback Close Controls
□ CB rate monitored weekly by merchant: flag any merchant approaching 0.50%
□ Network monitoring program status tracked (Visa VAMP / Mastercard ECP): accrue assessments on the current published schedule when enrollment occurs
□ Reserve coverage ratio assessed for every top-50 merchant monthly
□ ASC 450 assessment run for any merchant with coverage ratio <0.80x
□ Representment win/loss rate tracked by reason code: optimize representment strategy
□ Concessions, errors, and disputes classified correctly — separate GL accounts recommended
□ Pre-arb and arbitration cases tracked with fee exposure estimated and accrued
□ Net CB loss (after reserve recovery) tied to P&L charge-off line item
🔍 Controller Lens — Chargebacks & Disputes
WHAT CREATES THE EXPOSURE?Every cleared transaction within the chargeback window creates a contingent liability. Magnitude = CB rate × GTV within window × (1 − reserve coverage ratio).
SOURCE OF TRUTHNetwork chargeback file (daily). Internal CB tracking system. Reserve sub-ledger by merchant. ASC 450 assessment worksheet. All four must be consistent.
TIMINGCB filed → acquirer receives → notify merchant → representment within the applicable network window → resolution. ASC 450 accrual required when probable + estimable. Don't wait for month-end.
KEY RISKConcession misclassified as dispute. Reserve shortfall for insolvent merchant. Network monitoring program enrollment not accrued. Representment window missed = automatic loss.
Failure Scenario — Post-Holiday Merchant Insolvency
What happens: A direct-to-consumer retailer processes $8M in November and December on a 10% rolling 90-day reserve ($800K held). In January they file for bankruptcy. Between February and April, consumers dispute $1.2M in undelivered goods. The acquirer's reserve covers $800K. The gap is $400K of unrecovered CB exposure with no reserve backing it.

The accounting failure: The controller waited for actual chargebacks to arrive before running the ASC 450 assessment. The correct trigger was the bankruptcy filing in January — at that point the loss was probable (bankruptcy = merchant can't fund CBs) and estimable (historical CB rate × outstanding GTV window = estimated exposure). A $400K accrual should have been booked in January, not March when CBs hit.

P&L impact: $400K unbudgeted expense. Q1 earnings miss. Potential restatement if material.

Control: Monitor merchant news and public filings weekly for top-50 merchants by reserve exposure. Any insolvency indicator triggers same-day ASC 450 assessment at full theoretical exposure (GTV in CB window × historical CB rate × (1 − reserve coverage)).
Failure Scenario — Representment Window Missed
What happens: A $45,000 CB arrives from Visa on a legitimate card-present transaction. The merchant has clear evidence (signed receipt, EMV chip data, CVV match). The CB ops team queues it for representment, but a staffing gap means the response is filed after the applicable window has closed. The CB is lost on a deadline, not on the merits. The $45,000 becomes an unrecoverable expense.

The deadline is not one number. A workflow hard-coded to a remembered "45 days" is dangerous in both directions. Visa's current rules generally specify 30 calendar days for the relevant dispute responses and pre-arbitration attempts, with exceptions by condition — so a team working to 45 days may believe it has two weeks it does not have, and will lose otherwise winnable disputes without ever knowing why. Conversely, a single conservative deadline applied portfolio-wide creates artificial urgency on conditions that allow longer, wasting capacity. Deadlines must be configured by network, dispute condition and procedural stage (first presentment response, pre-arbitration, arbitration), and the merchant-facing deadline you set is typically shorter still, since you need time to compile and file.

Controller control: Representment deadlines are non-negotiable. Build a daily exception report: all CBs within 10 days of their representment deadline that have not yet been filed. Escalate to CB ops every day until filed or decision made not to fight. A missed window is always a finance failure, not an ops failure — the controller owns the loss.
Chapter 24

Breaking Into
Payments Finance

The 30/60/90 day career roadmap, credential strategy, 10-K case study framework, and how controllers build durable industry credibility — from first day in payments to recognized domain authority.

You've read the guide. You understand the four-party model, the fee waterfall, ASC 606's principal vs. agent framework, reserve methodology under ASC 450, and how network quarterly billing creates close risk. That knowledge alone puts you ahead of most people who carry a "payments finance" title. Now the question is how to operationalize it into a career trajectory. This section gives you the concrete playbook.

The 30 / 60 / 90 Day Roadmap

Whether you're new to acquiring or transitioning from Big 4 / FP&A into a controller role, the first 90 days are the highest-leverage window of your career in this domain. What you build in that window determines whether you're seen as someone who processes closes or someone who owns the business. The difference is intentional infrastructure-building.

30 / 60 / 90 Day Controller Ramp — Payments Finance
DAY 30 UNDERSTAND THE BUSINESS → Read every MPA template → Trace one transaction end-to-end → Pull and read last 3 CBS/MCBS → Map every GL account to source → Attend a settlement rec meeting → Read existing RevRec policy → Understand reserve methodology → Know top 20 merchants by GTV DELIVERABLE: One-page business overview: GTV, take rate, top merchants, key risks. Share with your manager. Signal: You're a strategic thinker DAY 60 OWN THE CLOSE → Run a complete month-end close → Build variance bridge (vol/rate) → Validate scheme fee accrual model → Run ASC 450 reserve assessment → Map quarterly fee billing cycle → Identify top 3 GL control gaps → Start reading one 10-K (Shift4) → Shadow risk on 2 merchant reviews DELIVERABLE: First full variance bridge memo. Present to FP&A. Call out the mix effect. Explain accrual methodology. Signal: You own more than the close DAY 90 BUILD INFRASTRUCTURE → Draft a RevRec policy memo → Document reserve methodology → Build scheme fee accrual model → Create close calendar + checklist → Start ETA CPP study plan → Propose 1 process improvement → Connect with payments peers (LI) → Present KPI dashboard to leadership DELIVERABLE: Draft controller handbook section. Even 5 pages on your RevRec policy is institutional knowledge that lasts. Signal: You're building the function

Year 1–4 Career Arc

PhaseFocusKey OutputsCredibility Marker
Year 1Technical fluency — payments mechanics, close process mastery, ASC 606 & 450 applied to your portfolioFirst variance bridge. First reserve adequacy memo. Scheme fee accrual model.You can explain any P&L line to any stakeholder without notes
Year 2Policy depth — write the frameworks that didn't exist. ASC 606 RevRec policy memo. Reserve methodology doc. Close calendar.SOX-quality technical memos. Controller handbook draft. First ETA CPP exam.You are the institutional memory of the accounting function
Year 3Cross-functional influence — risk, treasury, FP&A, legal. Own the FX exposure model. Build the margin bridge into the standard management pack.FX hedging framework. Merchant risk reserve model. Margin bridge as standard reporting.Finance leadership references your frameworks in board materials
Year 4+Domain authority — publish, present, mentor. Write publicly. Speak at ETA Transact. Build the team below you.Published content. Industry engagement. Team documentation library.Your name comes up when people discuss who knows payments accounting

The ETA Certified Payments Professional (CPP)

The CPP is the most recognized credential in the payments industry, administered by the Electronic Transactions Association (ETA). It covers payments technology, security (PCI DSS, EMV), business development, and operational mechanics across the acquiring value chain. For a finance professional, the CPP signals domain commitment and operational breadth — that you understand the business you're accounting for, not just the accounting.

Exam Format

100 multiple-choice questions. Six content domains: payments technology, risk and security, business development, industry operations, specialized markets, compliance. 3-year recertification cycle with continuing education requirements.

When to Pursue It

After 18–24 months in the industry. Studying before hands-on experience significantly reduces retention — the technical concepts need operational context to stick. Don't cram it in Month 2 to impress someone. Use it as a Year 2 milestone.

Controller-Specific Value

The CPP forces coverage of areas controllers rarely encounter day-to-day: PCI DSS scope and compliance tiers, ISO/PayFac model structures, gateway architecture, and the business development economics of the acquiring sales channel. All of it has accounting implications you'll use.

Best Study Resources

ETA CPP study guide (official). Glenbrook's Payments Systems in the U.S. — the definitive technical reference. Visa/MC public interchange tables and network operating regulations. This guide. In that order.

Reading Public Acquirer 10-Ks as Case Studies

The most underutilized free resource in payments finance education is the public 10-K. Annual reports of publicly traded acquirers contain their actual revenue recognition policies, reserve methodologies, segment structures, and risk disclosures — the output of exactly the accounting judgments you're building expertise on. One hour per quarter reading a competitor 10-K compounds faster than almost any other learning investment.

How to Read a Payments 10-K — Controller's Framework
Start with Note 2 (Summary of Significant Accounting Policies) — find their revenue recognition methodology. Is it gross or net? How do they describe performance obligations? Then go to the segment footnotes — how is take rate calculated and disclosed? Then risk factors — what do they call out as scheme fee risk, chargeback exposure, and FX risk? Finally read MD&A — how do they explain revenue changes? Volume effect vs. rate effect? This is the variance bridge language in public disclosure form.

Shift4 Payments (FOUR)

Best-in-class RevRec disclosure. Gross vs. net presentation detailed in Note 2. Gateway-vs.-acquiring segment economics clear. Study their revenue recognition note first — it's the most controller-relevant in the space.

Nuvei (NVEI)

Best cross-border and FX disclosures. Multi-currency acquirer with strong ASC 830 functional currency notes. Their take rate disclosure methodology is excellent for understanding how to build management reporting.

Adyen N.V.

Best take-rate economics disclosure. Processing vs. acquiring net revenue split is explicitly shown. PayFac model economics documented. Best public comparator for interchange-plus margin analysis.

Worldpay (legacy FIS filings)

Pre-divestiture FIS 10-Ks contain the most detailed interchange and scheme fee methodology disclosures of any public acquirer. Reserve methodology section is required reading for any controller building a reserve framework.

ASC Mastery Sequence — Priority Order

Learn the Four Reserve Standards Together, in This Order
The most common way an acquirer controller's technical foundation goes wrong is learning ASC 450 as "the reserve standard" and stopping there. It is one of four, and on its own it produces exactly the errors this handbook corrects elsewhere: merchant collateral booked as expense, CECL allowances never measured, and guarantee arrangements never scoped.

ASC 405-20 first — whose money is it? Merchant-funded reserves are liabilities.
ASC 326 next — what do merchants owe you, and what is the expected loss on it, from origination?
ASC 450-20 third — what contingent exposure remains beyond those recorded assets?
ASC 460 alongside — is the arrangement actually a guarantee?

Read in that sequence, the reserve chapters make sense. Read ASC 450 alone, and every balance labelled "reserve" looks like the same thing.
On the Rankings, Timelines and Productivity Claims in This Chapter
The month-by-month study sequence, the career-path rankings, the study-time estimates and the productivity comparisons in this chapter are the author's opinion and experience, offered as a starting point. They are not benchmarks, not survey findings, and not independently sourced. Adapt them to your own role, portfolio and starting point — someone joining an issuer, a PayFac or a bank-owned acquirer will need a different order and a different pace.
StandardPriorityAcquiring ApplicationWhen to Study
ASC 606Critical · Day 1MDR revenue gross vs. net, contract costs, performance obligations, variable considerationBefore your first close. Read FASB's implementation guide + your company's existing policy.
ASC 405-20Critical · Month 1Study this before the reserve standards. Merchant-funded reserves and withheld settlement are liabilities, not loss accruals — the deposit-versus-own-loss distinction that everything downstream depends onBefore you look at a single reserve journal. Most reserve errors in acquiring start here.
ASC 326 (CECL)Critical · Month 1Expected credit losses on merchant receivables, funded chargebacks, negative balances and fees billed in arrears — measured from origination, not on evidence of impairmentWith ASC 450, not after it. This is the allowance most acquirer reserve models omit entirely.
ASC 450-20Critical · Month 1Contingent exposures beyond recorded receivables — disputes not yet filed, program assessments not yet incurred. Probable and estimableBefore your first reserve adequacy assessment. Read it alongside 326 and 405-20, not instead of them.
ASC 460High · Month 2Guarantee scoping — assess whether an arrangement falls in scope rather than defaulting every contingent exposure to ASC 450When sponsorship, PayFac or first-loss arrangements appear in your portfolio.
ASC 830High · Month 3FX remeasurement of settlement receivables, CTA for foreign subsidiaries, functional currency determinationWhen you take on cross-border or multi-currency responsibilities.
ASC 815High · Month 6Hedge accounting for FX derivatives, effectiveness testing, documentation requirementsWhen treasury starts hedging FX exposure and needs accounting support.
ASC 842High · Year 1POS terminal rental (lessor accounting), operating vs. sales-type lease classificationWhen you're responsible for terminal asset accounting. Read lessor guidance specifically.
ASC 340-40Medium · Year 1Sales commission capitalization, contract acquisition costs, amortization over contract lifeWhen you own the contract cost asset balance. Review with sales comp team.

Building Credibility Through Documentation

In payments finance, credibility is built through documented intellectual work — not tenure. The controller who has written and defended a principal-vs.-agent analysis memo, built a reserve methodology framework from scratch, and published an internal training guide on interchange economics has built something no number of years of transaction processing can replicate: a portfolio of demonstrated accounting judgment applied to domain complexity.

Technical Accounting Memos

Document every significant judgment: the gross vs. net analysis, the reserve methodology rationale, the FX functional currency determination. Written at CAO-presentable quality. SOX-evidenced. These become your professional portfolio.

The Controller Handbook

A living document covering your team's close processes, accounting policies, reconciliation procedures, and judgment frameworks. Makes your knowledge institutional. When you leave, it stays. When you're promoted, it trains your successor. When you're audited, it's your evidence package.

Cross-Functional Visibility

Present at business reviews. Engage risk on reserve governance. Partner with treasury on hedge accounting. The controller visible beyond the close cycle builds influence compounding for years. The invisible one gets replaced by automation.

Industry Network

ETA Transact. Money20/20. Visa/MC acquirer conferences. LinkedIn content on controller topics in payments. Relationships in this industry accelerate your technical education faster than any book — people in payments share knowledge generously.

The Compounding Return on Domain Depth
The payments finance career path has a unique property: domain knowledge compounds in a way that generalist accounting does not. Every additional year of interchange expertise, every reserve methodology you've built, every FX framework you've documented makes the next accounting challenge in acquiring faster to solve. You build pattern recognition that junior accountants and generalist CFOs simply don't have. Protect and invest in that depth. It's your most defensible career asset.

Credentials & Certifications — Full Framework

The payments controller career has three parallel credential tracks: accounting/finance depth, payments domain, and technology fluency. The most valuable professionals in this space carry at least one from each track. Below is every credential worth considering, mapped by career stage, time investment, and the specific value it creates in a payments finance context.

Track 1 — Accounting & Finance Foundation

CredentialBodyCareer StageTime InvestmentPayments Finance Value
CPAAICPA / State BoardPre-entry or Year 1–212–18 months exam prep; 1–2 years experienceNon-negotiable baseline for controller-track at any bank or large acquirer. The single credential that opens every door. If you don't have it, get it — the domain knowledge you're building amplifies its value enormously in payments.
CGMACIMA / AICPAYear 3–52–3 years (CIMA pathway) or conversion from CPAChartered Global Management Accountant. Strong signal for CFO-track and commercial finance leadership. More strategy/commercial orientation than CPA. Well-recognized in UK/international payments companies.
CFA Level 1CFA InstituteYear 2–4300+ hours per levelUseful if moving toward treasury, FTP analysis, or hedge accounting leadership. Fixed income and derivatives content maps directly to ASC 815 hedge effectiveness testing. Not essential for pure controller track but differentiates for CFO-level roles.
CIAIIAYear 2–46–12 monthsCertified Internal Auditor. Valuable if transitioning from Big 4 audit to an internal audit or controls-focused payments finance role. SOX documentation and internal control frameworks are directly applicable to reserve methodology governance, revenue recognition memos, and network reporting controls.

Track 2 — Payments Domain Credentials

CredentialBodyCareer StageTime InvestmentPayments Finance Value
ETA CPPElectronic Transactions Assoc.Year 2–33–6 months study; 100-question examThe definitive payments industry credential. Signals operational breadth — ISO/PayFac models, PCI DSS, EMV, terminal architecture. For a finance professional, it proves you understand the business you're accounting for. Pursue after 18–24 months of hands-on experience so the operational content is meaningful.
AAP (Accredited ACH Professional)NachaYear 1–33–4 months study; annual examACH/bank transfer expertise. High value if your acquiring portfolio includes significant ACH-funded merchants, direct bank payments, or bank-to-bank settlement. Maps to ASC 606 recognition on ACH payment rails and settlement timing differences vs. card. Required knowledge for any controller working with embedded finance or bank-direct acquiring.
PCIP (PCI Professional)PCI Security Standards CouncilYear 1–21–2 days training; examEntry-level PCI DSS credential. Lightweight but signals data security fluency — directly relevant to acquirer compliance cost accruals, merchant compliance tier tracking, and PCI-related network fee exposure. Pairs well with FANF tier modeling (compliance status affects MID tier assignments).
Nacha Certified Payments ProfessionalNachaYear 3–5Experience + examBroader than AAP — covers full payments ecosystem including card, wire, and emerging rails. Useful for payments finance professionals at banks with multi-rail acquiring and issuing operations.

Track 3 — Technology & Data Intelligence

Credential / CourseProviderCareer StageTime InvestmentPayments Finance Value
Google Data Analytics CertificateCoursera / GoogleAny stage6 months part-timePractical SQL, spreadsheet, and data visualization skills. Directly applicable to building interchange cost models, settlement reconciliation tools, and variance bridges from raw network settlement files. The controller who can write a SQL query against the processing system database finds answers in minutes rather than waiting for an analyst.
Microsoft Power BI Data AnalystMicrosoft / CourseraYear 1–33–4 monthsHigh practical ROI for payments controllers. Build live KPI dashboards (GTV, MDR rate, IC rate, CB rate) that update from source systems. Replace static Excel close packages with interactive management reporting. Increasingly expected at senior controller level in fintech and bank payments.
Python for FinanceCoursera / edX / DataCampYear 2–43–6 months part-timeAutomate scheme fee accrual calculations, build reserve coverage ratio monitoring, and run card mix variance bridges programmatically. A controller who can write Python scripts for close automation is 10x more efficient and substantially harder to replace. Start with pandas and numpy — the data manipulation toolkit that maps directly to GL and settlement file analysis.
Alteryx Designer CoreAlteryxYear 2–420–40 hoursNo-code/low-code data automation platform widely used in finance. Build automated reconciliation workflows that pull settlement files, map to GL accounts, and flag exceptions without manual intervention. Common at Big 4 and large bank finance teams. If your company uses Alteryx, this certification pays back in days.
AWS Cloud PractitionerAmazon Web ServicesYear 3–52–3 monthsEntry-level cloud infrastructure literacy. Useful as acquiring and issuing platforms increasingly run on cloud infrastructure. Signals technical fluency for finance professionals working closely with engineering on system implementations, data pipeline design, or fintech platform migrations. Not essential for pure accounting roles but differentiates for CFO/VP Finance tracks.
Tableau Desktop SpecialistTableau / SalesforceYear 1–31–2 monthsData visualization. If your organization uses Tableau for management reporting, certification accelerates your ability to build controller-grade dashboards: margin decomposition, reserve adequacy monitoring, network fee trend analysis. Visual communication of complex P&L drivers is a senior controller skill that most accounting programs don't teach.

Track 4 — Project Management & Leadership

CredentialBodyCareer StageTime InvestmentPayments Finance Value
PMP (Project Management Professional)PMIYear 3–66–12 months; 35 contact hours + examEssential if leading ERP implementations, payment platform migrations, or accounting system upgrades. The PMP framework (scope, schedule, budget, risk) maps directly to the controller's role in finance transformation projects. In payments, these projects are frequent — every new product, new market entry, or network rule change has a system and accounting workflow component. The controller who can also lead the project is rare and valuable.
Certified ScrumMaster (CSM)Scrum AllianceYear 2–52-day course + examIf your organization runs Agile — common in fintech and bank technology divisions — CSM signals you can work in sprint-based development cycles. Useful for controllers embedded in product or engineering teams working on payment system builds. Lightweight investment (2 days) for significant credibility in Agile environments.
Six Sigma Green BeltASQ / VariousYear 3–63–6 monthsProcess improvement methodology. High value for controllers leading close process optimization — reducing day-count, automating reconciliations, eliminating manual interventions. The DMAIC framework (Define, Measure, Analyze, Improve, Control) is directly applicable to payments close redesign projects. Common at large bank payments operations teams.

Credential Priority Matrix — By Career Stage

StageMust HaveHigh Value AddForward Investment
Pre-entry / Year 1CPA (in progress or complete)Google Data Analytics, PCIPETA CPP study begins
Year 1–2CPA completePower BI, AAP (if ACH-heavy role)ETA CPP exam
Year 2–3ETA CPPPython for Finance, Alteryx CorePMP or CGMA decision point
Year 3–5ETA CPP + one data/tech credentialPMP (if leading implementations)CFA L1 or CGMA for CFO track
Year 5+Full credential portfolio (CPA + CPP + tech)Six Sigma Green Belt, CGMASpeaking, publishing, mentoring as credential
The Credential Strategy That Actually Works
Don't credential-collect. The most effective pattern: CPA first (non-negotiable baseline), then ETA CPP after 18–24 months in payments (domain credibility), then one technology credential matched to your organization's stack (operational leverage). Everything else is additive. The credentials that compound fastest in payments finance are the ones you can apply immediately. A Power BI build that improves your close dashboard this month is worth more than a credential that won't be relevant for two years. Prioritize domain fluency over credential breadth.
Chapter 22

AI & Agentic
Payments

How autonomous AI agents are reshaping payment initiation, authorization models, and the control frameworks controllers must build to manage machine-initiated spend at scale.

The next structural shift in payments is not a new card network or a faster settlement rail — it is the elimination of the human in the loop. AI agents capable of making purchasing decisions, initiating transactions, and managing multi-vendor spend autonomously are moving from research projects to production deployments. For the acquiring controller, this represents the most significant operational and accounting challenge since the transition to CNP e-commerce. This section maps the implications.

Traditional vs. Agentic Payment Flow

Traditional Human-Initiated vs. Agentic AI-Initiated Payment Flow
TRADITIONAL FLOW HUMAN Buyer INTENT + Auth / Checkout PAYMENT Initiated Stage 1: Human identifies need Stage 2: Human selects vendor, reviews price Stage 3: Human enters card / approves payment Stage 4: Human reviews receipt / confirms delivery Stage 5: Dispute requires human engagement ✓ Clear authorization: human identity established ✓ Dispute liability: human can testify to intent ✓ ASC 606 timing: delivery to human = clear event ✓ Reserve sizing: human behavior models exist AGENTIC FLOW AI AGENT Autonomous DECISION + No Human Review PAYMENT Initiated Stage 1: System/user defines goal (not transaction) Stage 2: Agent browses, evaluates, selects vendor autonomously Stage 3: Agent initiates payment via stored credential / API Stage 4: Agent confirms delivery / triggers next workflow Stage 5: Dispute has no human witness to intent ✗ Authorization: which identity? Agent or principal? ✗ Dispute: no human can attest to transaction intent ? ASC 606 timing: when does "delivery" occur to an agent? ✗ Reserve models: no behavioral history for AI spend NEW CONTROLLER FRAMEWORKS REQUIRED FOR AGENTIC PAYMENTS MODEL GOVERNANCE AI authorization policies AUDIT TRAIL REQUIREMENTS Immutable AI decision logs DISPUTE LIABILITY RULES Principal vs. agent framework RESERVE RE-CALIBRATION No historical CB data for AI Networks (Visa/MC) + Stripe + Major Acquirers: Building AI-native credential frameworks, tokenized agent identities, policy-bound spending controls

How AI Agents Initiate Payments

Current generation AI agents — including those built on Claude, GPT-4o, and Gemini — can be provisioned with payment credentials (virtual card numbers, API keys linked to payment accounts, or direct network API access) and authorized by their human principals to initiate purchases within defined parameters. The architecture typically involves:

Accounting & Control Implications for Controllers

The implications for acquiring controllers are not theoretical — they will arrive in your portfolio before your accounting policy frameworks are ready. The following are the specific areas where existing frameworks are inadequate and where new policy work is needed.

Revenue Recognition Timing

ASC 606's five-step model assumes a contract with a customer, performance obligations, and a transaction price. Agentic commerce does not change any of those. The customer is the person or entity that contracted — the enterprise or consumer on whose behalf the agent acts. An AI agent is software initiating a transaction under authority granted by that party; it is not itself a customer, has no legal capacity to contract, and does not become one by pressing the button. When is the performance obligation satisfied — at delivery of the digital good or service to the agent, or when the agent's principal benefits from it? For instantaneous digital deliveries (API calls, data, SaaS access), the timing question is narrow. For physical goods delivered to a location selected by an AI agent on behalf of a human, the question is more complex and the dispute window is potentially different.

Dispute and Chargeback Liability with No Human in the Loop

The existing chargeback reason code framework — grounded in human-intent disputes — does not adequately address AI-initiated transactions. If an AI agent purchases a service based on a misunderstanding of its principal's goal, is that "not as described" (13.3) or something else? If the agent is compromised by a prompt injection attack and makes unauthorized purchases, is that fraud (10.4)? Current network rules have not fully resolved agent-level liability, and this creates material uncertainty in acquirer reserve models.

Reserve Model Risk
Existing chargeback reserve models are calibrated on historical human-initiated dispute rates, and AI-initiated commerce has no meaningful historical dataset yet. That absence of data is the actual risk — and it cuts against confident claims in either direction.

Be careful what you assert as observed. Statements that early agentic deployments "have shown significantly different dispute and reversal patterns" require a dated study, dataset or filing to support them. Without one, the honest position is that the behavior is unknown, which is itself sufficient reason to treat these exposures with caution — you do not need an unsourced empirical claim to justify prudence, and including one weakens the memo that relies on it.

Uncertainty is a reason to test scenarios, not to raise the estimate arbitrarily. Under ASC 450 and ASC 326 the recorded amount still has to be an estimate of expected loss on supportable inputs. Run stress scenarios, disclose the estimation uncertainty, and update as data emerges — but do not book a conservative multiple as though it were a measurement.

Model Governance and Audit Trails

For SOX-compliant finance organizations, the introduction of AI agents into payment workflows requires a new class of IT general controls: model governance controls. These include documentation of model authorization scope, audit trail requirements for AI-initiated transaction decisions, periodic validation of model behavior against authorization policies, and change management procedures for model updates that could affect payment behavior. The audit trail question is particularly acute: in a dispute, can you produce an immutable log of why the AI agent made the purchase decision? Without this, the acquirer and merchant face an evidentiary gap in dispute proceedings.

How Networks Are Responding

Visa Intelligent Commerce

Visa's framework for AI agent payments introduces a concept of "agent credentials" — tokenized payment identities for AI agents, with policy enforcement at the network level. Merchants that accept agent-initiated transactions will receive new data fields identifying the agent, the principal, and the authorization policy version active at the time of purchase.

Mastercard Agent Pay

Mastercard's equivalent initiative focuses on delegated authorization — a formal model in which a human principal explicitly delegates payment authority to an AI agent, with that delegation recorded in the network's credential store. This creates a liability framework: if the agent acts within its delegated scope, the principal is liable; if it acts outside scope, liability allocation becomes contested.

Stripe Agent Toolkit

Stripe has released open-source toolkits enabling Claude and other AI models to directly initiate Stripe payment flows. These create programmable spending controls at the platform level before the transaction reaches the network — a new control layer that acquirers must understand and map to their own risk frameworks.

Acquirer API Evolution

Large acquirers are building AI commerce-aware APIs: merchant-level policy controls for accepting/rejecting agent transactions, real-time agent identity verification against network credential stores, and enhanced data fields in clearing messages to flag AI-initiated spend for downstream analytics and reserve modeling.

What Controllers Must Build Now

The controllers who will lead this transition are those who engage with the technical architecture before it reaches production scale in their portfolios. The following is the priority work queue:

Controller Action Plan — AI Payments Readiness
1. Policy Framework — Draft an AI-initiated transaction accounting policy that addresses revenue recognition timing, dispute treatment, and reserve methodology for AI commerce. Get CAO/technical accounting sign-off before the volume materializes.

2. Data Architecture — Ensure clearing data will capture AI agent identifiers when network standards are implemented. Build the subledger and GL account structure now so agentic volume can be segregated and analyzed.

3. Reserve Model Update — Build scenario analysis for AI-commerce dispute rates. The 2×, 5× and 10× cases are hypothetical stress tests, not evidence-based loss estimates — use them to size sensitivity and set escalation triggers, not to determine the recorded reserve. Establish a reserve adequacy review trigger when agentic volume exceeds a documented threshold.

4. Audit Trail Partnership — Partner with IT and the AI/model governance team to establish audit trail requirements for AI-initiated payment decisions. The controller's interest (dispute evidence) should be a primary input to the model logging specification.

5. Network Engagement — Assign someone in your team to track Visa and Mastercard's AI commerce rule updates. These are publishing faster than most compliance calendars can absorb.

Agentic Commerce — The Controller's Accounting Framework

When an AI agent initiates a payment on behalf of a user — booking travel, purchasing supplies, executing a subscription — several accounting questions emerge that traditional acquiring frameworks don't address. The agent holds a mandate (permission to spend), uses stored credentials or network tokens, and may transact across multiple merchants. Who bears the chargeback risk when the agent makes an error? How is the mandate liability recognised? When does revenue recognise?

Agentic Payment Flow — Controller Accountability Map
USER grants mandate AI AGENT Holds mandate + network token Initiates auth MANDATE LIABILITY Not yet a financial event NETWORK Visa / MC MERCHANT PSP processes CB RISK OWNER Who bears agent error disputes? ISSUER validates token mandate 0100 auth Open question: When agent transacts in error, dispute reason code = "not authorized by cardholder" — chargeback liability falls to acquirer/merchant unless mandate documented
Agentic Commerce Changes Who Presses the Button, Not the Accounting Tests
Three substitutions recur in agentic-payments analysis, and each replaces a settled concept with something that does not exist:

The agent is not the customer. ASC 606-10-20 defines a customer as the party that has contracted to obtain goods or services. That is the enterprise or consumer who granted the mandate. Identify the contracting party, then apply the normal analysis — who the service was promised to, and when control transfers. Software initiating the request changes neither.
The agent has no functional currency. Functional currency belongs to a reporting entity, so the exposures to model are the same ones you already model: the contracting party's currency, the settlement currency, and yours.
A mandate is not automatically a liability or a contingency. Permission to spend is an authorization. Whether it creates any obligation of yours depends on your contracts and the applicable rules, and must be established rather than assumed.

Where the genuine uncertainty lies is narrower and more practical: how authority is evidenced in a dispute, which dispute conditions apply when an agent transacts outside its mandate, what data the clearing record carries, and how liability allocates under the current network provisions. Those are real, dated questions with rules attached — cite the specific implemented capability or field, and keep it separate from announced development.
ASC 606-10-20 (customer), 25-1, 25-23; ASC 830-10-45-2 (functional currency); ASC 450-20-25-2. Current provisions: Visa Core Rules §4.1.24 (Agentic Platform Requirements); Visa Trusted Agent Protocol (published capability context, not proof of dispute outcomes).

Agentic Payments — Five Controller Questions

QuestionCurrent AnswerController Action
When does revenue recognise?At clearing, same as today — the payment rail doesn't change. The agent is just a new auth initiator.No change to RevRec timing. Monitor for new transaction types (mandate fees, subscription management fees) that may have different performance obligations.
Who bears CB risk on agent errors?Determined by the applicable network rules, the authority actually granted, and the facts of the specific dispute — not by a general rule that the acquirer always bears it. Both networks have published agentic requirements; check the current provisions rather than assuming the gap persists.Document the mandate framework and evidence of authority in the merchant agreement. Accrue only where a loss is probable and estimable on supportable inputs.
How is the mandate classified?A spending mandate is an authorization, not automatically a contingent obligation of the acquirer. Granting an agent permission to spend creates no obligation of yours unless something in your arrangements makes you liable — assess whether an enforceable obligation exists rather than assuming one.No balance sheet entry for the mandate itself. An unused spend limit is not an exposure in the ASC 450 sense any more than an undrawn card limit is a CECL commitment (Ch. 11). Track it operationally; accrue only a real obligation.
How do network tokens interact with existing IC tiers?Agentic tokens (network tokens used by AI agents) currently qualify for standard card-present or card-not-present interchange tiers depending on authentication method.Monitor which interchange tier agent transactions qualify for. If agents use stored credentials without 3DS, expect CNP rates — model the higher IC cost vs. card-present baseline.
What are the FX implications?Cross-currency transactions create the same exposures as any other. An agent has no functional currency — functional currency is an attribute of a reporting entity (ASC 830-10-45-2), not of software. The exposure arises between the contracting party's currency, the settlement currency and your own functional currency, exactly as it would for a human-initiated transaction.Ensure the FX remeasurement model captures agent-initiated cross-currency volume. Do not assume all agent transactions are domestic — but do not invent a new FX concept for them either.
Controller Watch-Out — Mandate Dispute Classification
A user authorises an AI agent to "book the cheapest flight under $500." The agent books a $487 flight. User disputes, claiming they didn't authorise that specific merchant. The network reason code is "transaction not recognised" — treated as an unauthorised transaction chargeback. The acquirer bears the loss unless the mandate documentation clearly establishes the scope of agent authority. As agentic payments scale, expect a new category of CB disputes that don't fit existing reason code frameworks. The controller who has built this into the reserve methodology before disputes arrive is significantly ahead of the one who hasn't.
Reference · Sources & Attestation

Sources &
Attestation

Every statement, framework, and example in this handbook is derived from publicly available accounting standards, regulatory filings, industry publications, and controller-style analysis. No proprietary, confidential, or employer-specific material is included.

Author Attestation

I, Nico Rivera, attest that the content of this handbook reflects publicly available information, generalized industry concepts, and my independent analysis. It does not reproduce, reference, or disclose proprietary information, confidential operating data, internal policies, internal systems documentation, trade secrets, or any materials from any past or present employer. Illustrative numbers are hypothetical and constructed to demonstrate accounting mechanics, not derived from any proprietary dataset.

Public Sources Used

This handbook is built on information drawn exclusively from the following categories of public sources. Every accounting treatment, technical framework, journal entry illustration, and operational description traces back to one or more of these.

1. US GAAP & Accounting Standards

Content referencing accounting standards is sourced from the FASB Accounting Standards Codification, which is publicly accessible at asc.fasb.org. Standards referenced include:

  • ASC 606 — Revenue from Contracts with Customers
  • ASC 450 — Contingencies (reserves and loss contingencies)
  • ASC 815 — Derivatives and Hedging
  • ASC 830 — Foreign Currency Matters
  • ASC 326 — Financial Instruments — Credit Losses (CECL)
  • ASC 350 — Intangibles — Goodwill and Other
  • ASU 2023-08 — Crypto Asset Accounting
  • ASC 340-40 — Contract Costs
  • ASC 842 — Leases

2. Card Network Rules & Published Materials

Discussion of interchange, scheme fees, chargeback programs, and network rules draws from publicly available materials:

  • Visa published interchange rate tables (semi-annual, public)
  • Mastercard published interchange rates (public, revised semi-annually)
  • Visa Core Rules and Visa Product and Service Rules (publicly distributed)
  • Mastercard Transaction Processing Rules (publicly distributed)
  • Network monitoring program documentation — Visa VAMP, Mastercard ECP/EFM (published by the networks)

3. Regulatory & Government Sources

  • SEC EDGAR public filings (10-K, 10-Q) from publicly traded acquirers and issuers
  • Federal Reserve payments research (Federal Reserve Payments Study)
  • CFPB rulings and guidance documents
  • State unclaimed property statutes (UUPA 2016 and state-specific escheatment laws)
  • OFAC and AML guidance (publicly available regulatory material)

4. Industry Publications & Research

  • The Nilson Report (industry publication, publicly available by subscription)
  • Glenbrook Partners: Payments Systems in the U.S. (published book)
  • PYMNTS.com industry reporting
  • Electronic Transactions Association (ETA) published materials and CPP certification content
  • Big 4 public audit and industry guides (Deloitte, PwC, EY, KPMG — all publicly distributed)
  • Public-domain industry conference materials and analyst reports

5. Author’s Independent Analysis

Analytical content — including the P&L bridge logic, variance decomposition framework, controller close calendar, reserve adequacy methodology, and scenario tool formulas — represents the author’s independent interpretation and synthesis of public sources. Worked examples use hypothetical numbers constructed to demonstrate accounting mechanics. Analysis is offered as general industry reference, not as a prescription for any specific company.

What This Handbook Does NOT Contain

Explicit Exclusions
  • No proprietary pricing, contract terms, or commercial arrangements from any employer
  • No internal systems documentation, architecture diagrams, or technical specifications
  • No confidential customer or merchant data — all examples use hypothetical merchants
  • No internal accounting policy memos or technical accounting positions
  • No references to internal procedures, controls, or operational workflows
  • No disclosure of internal financial results, reserve levels, or performance data
  • No reproduction of any copyrighted training materials or employer-owned content
How to Read the Numbers, Thresholds and Benchmarks in This Handbook
Content here falls into four categories, and they carry very different weight. Where a figure is not explicitly cited to a dated primary source at the point it appears, assume the second or third category:

1 · Accounting requirements — cited to the ASC. Authoritative, and checkable at asc.fasb.org.
2 · Illustrative figures — the two portfolio scenarios, worked journals, example rates and sample calculations. These exist to make the mechanics legible. They are internally consistent and arithmetically verified, and they are not market data.
3 · Proposed controls and thresholds — coverage ratios, escalation triggers, aging limits, KPI floors. These are suggested starting points to calibrate against your own portfolio, not requirements. Nothing in GAAP or the network rules establishes them.
4 · Network rules and program parameters — cited where public. Thresholds, fee codes and dispute windows change on network release cycles and differ by participant, region and product; verify against the current rulebook and your own billing schedule before relying on any of them.

Prescriptive wording does not upgrade a category. Where the text says "always," "never," "required" or "must" about an operational practice rather than an accounting requirement, read it as emphasis on a recommended control — and if you need to defend it, find the underlying authority or restate it as your own policy choice.
ASC 275-10-50 (disclosure of risks and uncertainties); ASC 326-20-30-2 and ASC 450-20-25-2 for estimates. No ASC or network authority establishes the illustrative benchmark values used in this handbook.

Verification

Auditors, compliance reviewers, or curious readers can verify that this handbook's content derives only from public sources by following these steps:

  1. Any GAAP-related claim can be checked against the FASB Codification at asc.fasb.org, which is the authoritative source (ASC 105-10-05-1). An ASU explains an amendment; the Codification as amended is what governs.
  2. Interchange references can be checked against the networks' published interchange schedules — scheme fee references generally cannot. Participant-level commercial tariffs, billing cycles and technical file interfaces are not published in the public rulebooks, and the networks' own documents say so. Figures of that kind in this handbook are illustrative and must be verified against your own network billing schedule.
  3. 10-K disclosure examples can be verified against the cited company's most recent SEC filing on EDGAR.
  4. All illustrative dollar figures are hypothetical — none represent actual volume, revenue, or results from any real company.
  5. Author attestation (above) confirms no proprietary content has been used.
What This Handbook's Sourcing Does and Does Not Establish
The list above establishes provenance — that the content derives from public sources. It is not claim-level substantiation, and readers should not treat it as such. Three distinctions worth stating plainly:

A source category is not a citation. "Visa and Mastercard rules" supports the existence of a framework; it does not substantiate a specific rate, threshold, fee code or file interface. Where this handbook states such a figure, it is illustrative unless a dated primary source is cited at that point.
Some things cannot be publicly verified at all. Participant pricing schedules, billing cycles by fee code, implementation-specific technical interfaces, and individual merchant, ISO or sponsorship contract terms are not public. Claims depending on them are assumptions, and are flagged as such where they appear.
Empirical benchmarks need their own support. Margin bands, KPI ranges, default rates, market sizes and productivity claims require a dated dataset, filing or issuing-body source with a stated methodology and population. Where none is cited, treat the figure as the author's illustration or experience — not as an observed industry fact.

A content review is not an attestation. Technical review of accounting treatment, arithmetic and sourcing says nothing about the author's confidentiality and provenance statement above, which stands on its own and is not verified by that process.

Maintenance: keep a claim-to-source register mapping each substantive assertion to its dated primary source or, where none exists, to the assumption it rests on. Record a review date only when a review was actually performed.
ASC 105-10-05-1 (authoritative GAAP). Public network documents expressly omit participant commercial terms — see the introductions to the Visa Core Rules and Mastercard Security Rules and Procedures §8.3.

Contact for Audit Support

If you are an auditor, compliance reviewer, or employer representative and require additional sourcing detail or attestation for a specific statement in this handbook, contact the author directly:

Nico Rivera

Email: nriver927@gmail.com

Subject line prefix: Audit Support Request

Responses typically within 48 hours. Source verification for specific statements can be provided on request.

Version & Change Control

// VERSION HISTORY
v2026.2 — Controller Edition (current)
Last reviewed: September 2026
Next review: June 2027 (annual cadence)
Material updates to GAAP interpretation, network rules, or regulatory guidance are incorporated at each scheduled review, and sooner where a change is material to a stated conclusion. Significant changes are logged in the changelog and disclosed in-line where relevant. Illustrative rates, thresholds and network program parameters are dated where quoted and should be re-verified against current primary sources before use.

This attestation and sourcing statement is offered in good faith to document the author’s commitment to content originality and respect for intellectual property and confidentiality obligations. It is provided as supplementary reference material for readers who require transparency about content provenance, including auditors, compliance reviewers, and employers conducting standard due diligence on public authorship.

Glossary

Payments & Finance
Terminology

110+ essential terms spanning merchant acquiring, payments finance, accounting standards, and emerging AI payments — controller-grade definitions.

⌕
ACH (Automated Clearing House)
US electronic network for credit and debit transfers. Governed by NACHA. Used for merchant DDA funding, payroll, and B2B payments. Settlement typically T+1 or same-day (same-day ACH for qualifying entries).
ACH is how most merchant DDAs are funded. Track same-day ACH separately — it changes your T+1 settlement receivable timing and cash flow forecast.
Acquirer / Acquiring Bank
The financial institution (or its processor) that maintains the merchant's card acceptance relationship. Signs the merchant processing agreement, bears credit risk on the merchant, and is responsible under network rules for the merchant's transactions.
You work for one. Understand the distinction between the bank (regulatory risk owner) and the processor (operational executor) — your GL entries may span both entities.
Agentic Commerce
The emerging model in which AI software agents autonomously initiate, authorize, and complete commercial transactions on behalf of human or enterprise principals, without per-transaction human approval.
No controller framework yet exists for AI-initiated transactions. Your first job: ensure existing ASC 606 performance obligation analysis still holds when there is no human completing the purchase.
ASC 340-40
FASB standard governing costs of obtaining and fulfilling contracts with customers. Requires capitalization of incremental contract acquisition costs (e.g., sales commissions) when recoverable. Amortized over expected contract life including probable renewals.
Applies when you capitalize sales commissions paid to ISOs or internal reps. Amortization period must match the expected customer life — get this wrong and you have a restatement risk.
ASC 450
FASB standard governing loss contingencies, accrued when probable and estimable. In acquiring it governs contingent exposures beyond recognised assets — disputes not yet filed, program assessments not yet incurred.
Not "the reserve standard." It is one of four, and using it alone is the most common source of reserve error in acquiring. Merchant-funded collateral is a liability under ASC 405-20 and never a loss accrual. Amounts merchants owe you carry an expected-loss allowance under ASC 326, measured from origination. Guarantee-type arrangements may fall under ASC 460. Ask whose money it is and who the obligor is before choosing the standard.
ASC 606
Revenue from Contracts with Customers. The five-step model governing revenue recognition across industries. Governs MDR revenue, gross vs. net presentation, performance obligation identification, and contract modification accounting in acquiring.
Governs all MDR and processing fee revenue. The principal vs. agent and gross vs. net decisions made under 606 are the most consequential accounting judgments in merchant acquiring.
ASC 815
Derivatives and Hedging. Governs the accounting for derivative instruments and qualifying hedge relationships. Relevant to acquirers using FX forwards or swaps to hedge settlement currency exposure.
Applies to FX hedges and interest rate hedges. Designation at inception is non-negotiable — a late memo means MTM through income instead of OCI. Date-stamp everything.
ASC 830
Foreign Currency Matters. Governs remeasurement of foreign-denominated monetary items (FX gains/losses through income) and translation of foreign subsidiary financial statements (CTA through OCI).
Governs translation of foreign-currency merchant portfolios. CTA sits in OCI, not income — understand what triggers reclassification to avoid surprises on entity liquidation or intercompany settlement.
Assessment Fee
Fee charged by the card network (Visa, Mastercard) to the acquirer, assessed as a percentage of transaction volume. Separate from interchange, which goes to the issuer. Also called "scheme fees."
Your second-largest scheme cost after interchange. Accrues daily but bills monthly in arrears. The unbilled days at month-end must be estimated — grow the accrual with volume growth, not just prior-month actuals.
Authorization
Real-time approval request from merchant to issuer (via acquirer and network) confirming the card is valid, has sufficient funds/credit, and is not flagged for fraud. Does not move money. Creates a hold on the cardholder account.
The auth-to-capture gap is a key reconciliation item. Authorized amounts that never capture are revenue that never lands — track the conversion rate as a leading indicator of merchant health.
Basis Points (BPS)
Unit of measure equal to 0.01% or 1/100th of a percent. Standard unit for expressing interchange rates, acquirer margins, and fee economics. 100 bps = 1.00%. $1,000 in volume at 100 bps = $10.00 in fees.
The universal unit in payments finance. Convert everything to bps of GPV for comparability across periods, pricing models, and merchant segments. A 1bps move on $1B GPV is $100K.
BIN (Bank Identification Number)
First 6–8 digits of a card number identifying the issuing institution and card type. Used by the network to route authorization requests and by the acquirer to determine expected interchange category for incoming transactions.
BIN-level data is how you identify card type, issuer, and geography before interchange is billed. Good BIN data means better interchange accrual accuracy — poor BIN data means constant true-ups.
Chargeback
A forced transaction reversal initiated by the issuer on behalf of the cardholder, returning funds to the cardholder and debiting the acquirer's settlement account. The acquirer must then recover the funds from the merchant or from merchant reserves.
The financial exposure event, not just an operational one. Net unrecovered chargebacks hit your P&L. Gross chargebacks hit your reserve. Track both, report both, and explain the difference.
Clearing
The submission of final transaction data (post-authorization) to the card network for financial settlement. The clearing message initiates the interchange calculation and triggers the movement of funds. The event that determines interchange qualification.
Revenue recognition trigger under ASC 606 for most acquirers. The clearing date — not the auth date and not the settlement date — is when the performance obligation is satisfied.
CNP (Card-Not-Present)
Transaction category in which the physical card is not presented at a terminal — includes e-commerce, phone orders, and app-based purchases. Higher interchange rates than card-present; higher fraud rates; no EMV liability shift protection.
Higher interchange rate, higher chargeback rate, higher fraud rate. Your reserve adequacy models should use separate chargeback rate assumptions for CNP vs. card-present portfolios.
CTA (Cumulative Translation Adjustment)
Accumulated OCI balance arising from translating foreign subsidiary financial statements into the parent's reporting currency under ASC 830. Recycled through income upon disposal of the foreign subsidiary.
Lives in AOCI, not retained earnings. Does not affect current-period income — until the foreign entity is sold or liquidated, at which point it reclassifies all at once. Know your CTA balance.
DCC (Dynamic Currency Conversion)
Service offered to foreign cardholders at point of sale, converting the transaction to their home currency. The acquirer earns a margin on the FX spread. Cardholder disclosure is required by network rules.
DCC revenue is high-margin and should be tracked separately. It is often misclassified as interchange or FX income — get the revenue line right before you can manage it.
Downgrade
When a transaction fails to qualify for the intended (lower-cost) interchange rate and is assessed at a higher-cost rate tier (e.g., EIRF or Standard). Caused by missing data elements, late clearing, incorrect MCC, or other qualification failures.
The single largest source of interchange cost variance. When transactions do not qualify for their intended rate tier, they fall to a higher-cost category. Downgrade % is a key metric to track monthly.
Durbin Amendment
Section 1075 of the Dodd-Frank Act (2010) capping debit interchange for issuers with ≥$10B in assets at $0.21 + 0.05% + $0.01 fraud adjustment per transaction. Dramatically reduced debit interchange cost for merchants.
Caps debit interchange for large issuers. As an acquirer, Durbin-regulated debit is your lowest-cost transaction type. Monitor debit mix as a separate segment — it materially affects blended interchange.
EIRF (Electronic Interchange Reimbursement Fee)
Visa downgrade rate tier applied when transactions fail to qualify for specialized rates but are submitted electronically. Typically 2.30% + $0.10. Higher than most card-present qualified rates but lower than Standard.
A downgrade destination. Transactions landing in EIRF are costing you significantly more than their intended rate. High EIRF volume signals a data quality or authorization practice problem worth investigating.
EMV (Europay, Mastercard, Visa)
Global standard for chip card transactions. Chip cards generate a unique cryptogram per transaction, dramatically reducing counterfeit fraud. Post-EMV liability shift (October 2015 in US) moved counterfeit fraud liability to the party not supporting chip.
Chip-present transactions get better interchange rates and shift fraud liability to the issuer. Track EMV penetration by merchant segment — it directly affects both interchange cost and chargeback exposure.
ETA CPP
Electronic Transactions Association Certified Payments Professional. Industry credential covering payments technology, operations, risk, compliance, and business development. 100-question exam with 3-year recertification.
The industry credential for payments professionals. If you are building domain expertise in payments finance, this signals commitment and provides a structured framework for the operational knowledge required.
FANF (Fixed Acquirer Network Fee)
Visa monthly fee assessed per merchant location (MID), tiered by the location's transaction volume. Can be a material fixed cost for acquirers with large SMB portfolios of low-volume merchants.
A fixed quarterly fee from Visa based on merchant location count and MCC — not volume. It does not scale with GPV, making it a fixed cost in your scheme fee model. Accrue quarterly, not monthly.
Four-Party Model
Open-loop card payment architecture: Cardholder ↔ Issuer ↔ Card Network ↔ Acquirer ↔ Merchant. The network facilitates settlement but does not hold funds. Contrast with three-party model (Amex original) where network also issues.
The structural foundation of everything in acquiring finance. Every fee, every accounting entry, and every risk exposure traces back to one of these four parties. Know who bears what risk at each stage.
Gross-to-Net Revenue
The conversion from total MDR billed to merchants (gross revenue) to net revenue after deducting interchange and scheme fees. The "acquirer take rate" is the net revenue expressed as basis points on GTV.
The core revenue presentation question in payments. Know whether your company presents gross (full MDR as revenue, interchange as cost) or net (spread only). ASC 606 principal vs. agent drives this — not management preference.
GTV (Gross Transaction Value)
Total card transaction volume processed by an acquirer, expressed as the face value of transactions before any deductions. Top-line KPI for acquirer scale. Distinct from acquirer net revenue, which is a small fraction of GTV.
The top-line volume metric but not the revenue base. Net revenue is a small fraction of GTV. When executives focus on GTV growth, the controller must translate that to net revenue impact using take rate.
Interchange
Fee paid by the acquirer to the issuer on each card transaction, set by the card network. Represents compensation to the issuer for credit risk, funding, fraud, and rewards. The largest single cost item in merchant acquiring economics.
The largest single cost line for most acquirers. Its complexity — hundreds of rate categories, quarterly changes, volume-based incentives — means your interchange accrual model must be rebuilt or validated every time Visa or MC publishes new rates.
ISA (International Service Assessment)
Visa fee on cross-border transactions where the card is issued outside the merchant's country. Assessed to the acquirer as a percentage of the transaction volume. Typically 0.45–0.80% depending on transaction type.
A significant cost on cross-border volume. Easy to under-accrue if your volume estimates do not separately model international mix. Track cross-border % of GPV as a separate KPI.
ISO (Independent Sales Organization)
A third party registered with the card networks that markets and sells merchant processing services under a sponsoring acquirer's umbrella. The ISO does not bear direct network settlement risk — the sponsoring acquirer does. ISO economics are typically residual-based.
Your partner and your revenue share liability. ISO residuals are a monthly accrual based on net revenue — confirm the contractual definition of "net revenue" matches your GL definition.
Issuer
The financial institution that issues payment cards to cardholders and extends credit or manages debit accounts. Receives interchange income. Bears fraud and credit risk on the cardholder side. Approves or declines authorizations.
The other side of every transaction you process. Understanding issuer economics — interchange revenue, rewards cost, credit loss — helps you understand why issuers decline transactions and how chargeback rules are structured.
MCC (Merchant Category Code)
A four-digit code assigned by the acquirer to classify the merchant's business type. Used by networks to determine interchange rates, by issuers for reward classifications, and by regulators for transaction monitoring. Assignment of the correct MCC is an underwriting and compliance function.
MCC determines interchange rate, chargeback rules, and some scheme fees. MCC misclassification creates interchange variance and potential compliance exposure. Audit your top merchants annually.
MDR (Merchant Discount Rate)
The total fee charged by the acquirer to the merchant, expressed as a percentage of transaction value. Includes interchange, scheme fees, and acquirer margin. The merchant receives the transaction value net of MDR.
The revenue rate. Your revenue accrual is GPV times MDR times the appropriate billing period. When volume or mix shifts intra-period, the MDR-based revenue accrual needs to flex accordingly.
MID (Merchant Identification Number)
Unique identifier assigned by the acquirer to each merchant location or processing entity. The granularity at which settlement, fees, reserves, and chargebacks are tracked. A single merchant may have multiple MIDs (e.g., one per store location).
The atomic unit of your reconciliation. Every settlement file, chargeback, and reserve balance should be traceable to a MID. MID-level reconciliation is the foundation of accurate acquirer accounting.
Model Governance
In the context of AI payments: policies, controls, and documentation frameworks governing the authorization scope, behavior, and auditability of AI models that initiate or influence financial transactions. An emerging SOX control domain.
Any quantitative estimate used in financial reporting — chargeback reserve rates, interchange accrual models, revenue recognition formulas — is a model requiring documentation, validation, and change control under SOX.
NABU (Network Access and Brand Usage)
A Mastercard fee — not Visa, and not "Network Acquirer Processing Fee." Charged per transaction rather than on transaction value. Visa's comparable per-authorization charge is the Acquirer Processing Fee (APF); the two are distinct fees on distinct networks and must be modeled separately.
Count-driven, not value-driven: high-frequency, low-ticket merchants generate disproportionate cost from fees of this type, and a basis-point cost model will understate it. Convert per-item fees to an effective bps equivalent at the merchant's own average ticket. Source the current rate and trigger from your network billing schedule — per-item tariffs are participant-specific and are not published in full in the public rulebooks.
PayFac (Payment Facilitator)
A model in which a single master merchant (the PayFac) boards sub-merchants under its own MID, absorbing network risk and underwriting responsibility. PayFacs underwrite and fund their sub-merchants and bear direct chargeback and fraud risk. Stripe, Square, and Toast are examples.
If your company is a PayFac or processes PayFacs as merchants, the sub-merchant liability aggregation changes your reserve and chargeback exposure model. Treat PayFac volume separately.
Principal vs. Agent (ASC 606)
The determination of whether an entity recognizes revenue on a gross basis (principal) or net of costs (agent), based on whether it controls the specified good or service before transfer to the customer. One of the most consequential and judgment-intensive determinations in acquiring revenue recognition.
The most consequential accounting judgment in payments revenue recognition. Getting this wrong mis-states revenue by the full interchange amount on every transaction. Document the analysis, get auditor concurrence, and do not change it without technical accounting review.
Representment
The merchant's response to a chargeback, submitting evidence through the acquirer to the issuer that the transaction was valid. If representment is successful, the chargeback is reversed and funds returned to the merchant.
The recovery event that reduces net chargeback expense. Track representment win rate by reason code and merchant segment — it directly informs your reserve adequacy model.
Reserve
Funds withheld from merchant settlements by the acquirer as a security buffer against future chargeback and refund obligations. Structured as rolling, capped, or upfront reserves. Accounted for as a merchant reserve liability on the acquirer's balance sheet, not revenue.
A contingent liability under ASC 450. The reserve is not cash held — it is an accounting liability. The corresponding asset is typically a separate restricted cash or funded reserve account. Confirm the asset and liability are both on your balance sheet.
Settlement
The actual movement of funds between issuers and acquirers through the card network, netting all cleared transactions on a given processing day. The financial event that triggers revenue recognition and cash receipt on the acquirer's books.
The cash event. Revenue recognition happens at clearing; cash comes in at settlement. The T+1 or T+2 gap creates a settlement receivable on your balance sheet. Reconcile it daily.
Take Rate
Acquirer net revenue divided by GTV, expressed in basis points or percent. The primary profitability metric for comparing acquirers and merchant segments. Net take rate = MDR minus interchange minus scheme fees. Gross take rate = MDR only.
Net revenue divided by GPV. The single most useful metric for acquirer profitability management. A falling take rate with growing GPV is the most common masking problem in acquiring P&Ls.
Tokenization
Replacement of a card's primary account number (PAN) with a unique surrogate token that has no intrinsic value outside its specific use context. Network tokens (Visa Token Service, Mastercard Digital Enablement Service) reduce fraud risk in card-on-file and device-bound transactions.
Network tokenization (VTS/MDES) reduces fraud and improves auth rates. It also changes your data flow — token-based transactions may require additional mapping to reconcile to original PANs for chargeback matching.
Variable Consideration (ASC 606)
Revenue that is contingent on future outcomes — volume discounts, refunds, chargebacks, price concessions. Must be estimated and constrained to the amount not likely to be reversed. Interchange-plus structures create variability in acquirer take rate that must be assessed under this guidance.
Volume rebates, tiered pricing adjustments, and performance-based fee concessions all create variable consideration that must be estimated and constrained before revenue can be recognized. Document the estimation methodology.
3DS / 3D Secure
Authentication protocol (Visa Secure / Mastercard Identity Check) adding a cardholder verification step in CNP transactions. 3DS2 uses passive device fingerprinting + risk-based authentication. Successful 3DS shifts fraud liability from acquirer/merchant to issuer. Critical for CNP interchange qualification and chargeback defense.
Shifts fraud liability to the issuer on authenticated transactions. As an acquirer, 3DS authentication data in your transaction flow reduces your chargeback exposure but adds processing complexity.
AVS (Address Verification System)
Real-time check of the billing address and ZIP code provided in a CNP transaction against the issuer's records. Returns a match code (full match, partial, no match). Full AVS match is often required for CNP interchange qualification and is a key input to fraud scoring. Failure to pass AVS can trigger downgrade.
AVS mismatch on CNP transactions is both a fraud signal and a downgrade trigger. If merchants are not passing AVS data correctly, you are likely leaving money on the table through unnecessary interchange downgrades.
Batch / Batch Capture
The end-of-day process by which a merchant's terminal or payment system closes its open authorizations and submits them to the acquirer for clearing. Batch timing determines clearing date, which determines settlement date and interchange qualification. Late batches (>24hr post-auth) risk EIRF/Standard downgrade.
Batch timing determines the clearing date and thus the revenue recognition period. A batch submitted at 11:58 PM vs. 12:02 AM can shift a day's revenue between reporting periods. Know your merchant batch cut-off times.
Blended Rate / Flat Rate
MDR pricing model in which the merchant pays a single fixed percentage regardless of card type or interchange tier. Acquirer absorbs card mix risk — high-interchange cards compress margin; debit-heavy mix improves it. Revenue recognition is simple; margin forecasting requires card mix modeling. Standard PayFac model (Stripe 2.9% + $0.30).
Presents cleanly to merchants but creates interchange cost variance on the acquirer side. When card mix shifts (more rewards cards, more CNP), the blended rate stays flat but your cost rises. Model the mix risk separately.
Capture
The process of finalizing a pre-authorized transaction for settlement. Capture confirms the transaction amount (which may differ from the authorized amount within tolerance) and triggers the clearing cycle. Distinct from authorization — an authorized but uncaptured transaction never clears and never settles.
The trigger for clearing and revenue recognition. A pre-auth without capture is a balance sheet item (contingent receivable) but not revenue. Monitor uncaptured auth aging — old uncaptured auths that expire are not revenue and should never appear in your revenue accrual.
Card Mix
The distribution of card types (consumer credit, rewards, debit, commercial) within a merchant's transaction volume. Card mix is the primary driver of interchange cost variability in blended-rate pricing. A merchant shifting from debit-heavy to rewards-credit-heavy volume can see interchange cost increase 100–200 bps with no change in pricing — a material margin compression event.
The primary driver of interchange cost variance that is outside your control. When card mix shifts toward premium rewards cards, your interchange cost rises even if volume, rate, and merchant mix are unchanged. Track card mix as a separate bridge line.
Chargeback Rate
Chargebacks as a percentage of total transactions, calculated as: (CB Count / Transaction Count) × 100. Note that the networks' own monitoring programs do not all use this construction: Visa's VAMP measures a count ratio against settled CNP transactions, and Mastercard's ECP compares current-month chargebacks to prior-month transactions. Use each program's own definition when testing against its thresholds rather than a single internal rate.
The key reserve driver. A rising chargeback rate on a growing portfolio requires a double-compounding reserve build — both the rate and the base are moving. Model them separately in the reserve adequacy tool.
Chargeback Reason Code
A standardized code assigned by the issuer to classify the basis for a chargeback. Visa uses numeric codes (10.x fraud, 11.x authorization, 12.x processing error, 13.x consumer dispute). Mastercard uses numeric codes (4853, 4837, etc.). Reason code determines the representment requirements and time limits for the merchant's rebuttal.
Reason code distribution tells you whether your chargeback exposure is fraud-driven (requires merchant controls) or dispute-driven (requires representment investment). The economics and reserve implications differ materially by code category.
Contactless / NFC
Near-field communication (NFC) payment method enabling tap-to-pay transactions using cards, smartphones, or wearables. Contactless transactions qualify for card-present interchange rates (better than CNP) and often qualify for the same tier as EMV chip. Contactless volume surged post-pandemic and is now the dominant form factor in many markets.
Contactless has specific interchange rate implications and different fraud liability rules vs. contact EMV. Track contactless separately in your transaction mix for accurate interchange modeling.
CVV / CVV2 / CVC2
Card Verification Value — a 3 or 4-digit security code on the card. CVV1 is encoded on the magnetic stripe (read at POS). CVV2/CVC2 is the printed code used for CNP verification. CVV3 is the dynamic code generated per-contactless-tap. CVV2 verification in CNP transactions is required for most interchange qualification and is a PCI-sensitive data element that cannot be stored.
CVV presence or absence in an authorization request affects both interchange qualification and fraud liability. Missing CVV on CNP transactions is a common downgrade trigger and a fraud risk indicator.
ECP (Excessive Chargeback Program) — Mastercard
Mastercard's chargeback monitoring program, with ECM and HECM categories. Its ratio compares current-month chargebacks to prior-month transactions — a period offset that a same-month calculation will not reproduce. Fraud is monitored separately under EFM, so a merchant can breach one program and not the other. The current merchant rulebook directs precise thresholds and assessments to Mastercard's monitoring and pricing resources; older flat fine tables are not substantiated as current.
Build the prior-month denominator into your KPI dashboard, or you will under-predict breaches on merchants whose volume is falling while disputes persist. Assess ECP and EFM separately.
FedNow
Federal Reserve's instant payment rail, launched July 2023. Enables 24/7/365 real-time credit push payments between participating banks, settling in seconds with finality. Not a card network — no interchange, no chargebacks. Controller implication: FedNow-funded merchant receivables settle with immediate finality, eliminating the ACH return window exposure. Growing adoption among fintechs and embedded finance platforms.
Instant settlement means zero float — and zero FTP income on those transactions. Every merchant shifted to FedNow or RTP reduces your settlement float balance. Model the revenue impact before pricing instant settlement products.
Floor Limit
The maximum transaction amount at which a merchant may accept a card without obtaining online authorization. Historically used in low-connectivity environments (paper vouchers). Today effectively zero — online authorization is required for virtually all card transactions. "Zero floor limit" means every transaction requires authorization; violation triggers a network fee ($0.20 Visa zero-floor-limit fee).
Relevant primarily for offline or stand-in authorization environments. Transactions processed below floor limit without authorization create increased fraud and chargeback exposure — track offline transactions separately.
Gateway
A payment gateway is the technology layer that securely captures, encrypts, and transmits payment data from the merchant's point of sale or e-commerce checkout to the acquirer's processing system. Gateways are distinct from processors — a gateway handles the data routing; a processor handles the clearing and settlement. Some acquirers own both; others partner with third-party gateways (Authorize.net, Braintree, NMI).
The gateway is often the first point of data capture. If the gateway does not pass Level 2/Level 3 data or correct MCC routing, interchange downgrades happen before the transaction ever reaches your processing system.
Interchange-Plus (I++)
MDR pricing model in which the merchant pays actual interchange cost plus a fixed acquirer markup (bps + per-item). Example: "IC + 25bps + $0.08." Maximum pricing transparency — the merchant sees exactly what interchange their transactions qualify at. Acquirer margin is fixed and predictable. Favored by high-volume merchants. Requires the acquirer to pass interchange at cost and earn only the markup as gross revenue.
The most transparent pricing model and the easiest to reconcile — you can directly compare interchange billed to interchange passed through. If you offer blended rates, your interchange cost is embedded and harder to audit.
ISO 8583
International standard for financial transaction card message interchange. Defines the format of authorization, clearing, and reversal messages between merchants, acquirers, and card networks. Each message type is identified by a Message Type Indicator (MTI): 0100 = authorization request, 0110 = authorization response, 0200 = financial transaction request, 0800 = network management. Every card transaction traverses this protocol.
The message format standard for card transactions. As a controller you do not code these, but understanding field 4 (amount), field 48 (additional data including Level 2/3), and field 63 (settlement data) helps you understand why interchange reconciliation breaks.
Level 2 / Level 3 Data
Enhanced transaction data submitted at clearing for commercial card transactions. Level 2 requires customer code, tax amount, and merchant postal code. Level 3 requires full line-item detail (item description, quantity, unit price, extended amount). Providing Level 3 data qualifies purchasing/corporate cards for significantly lower interchange (Corporate Data Rate III at ~1.80% vs. Standard at 2.95%). Critical for B2B acquirers and ERP-integrated payment flows.
Passing Level 2/3 data on B2B transactions qualifies for significantly lower interchange rates. If your merchant base includes corporate purchasers and you are not tracking Level 2/3 qualification rates, you are likely overpaying interchange.
Merchant Processing Agreement (MPA)
The contract between the acquirer and the merchant governing card acceptance. Key provisions: pricing schedule, volume minimums, term and auto-renewal, early termination fee, reserve requirements, chargeback liability, indemnification, acceptable use policy, and network compliance requirements. The MPA is the ASC 606 "contract with a customer" — its terms drive every revenue recognition and liability accounting judgment.
The contract that governs your financial relationship with each merchant. Reserve terms, MDR, chargeback liability, and termination provisions all live here. Your accounting entries must match the MPA — if they do not, you have a contract interpretation issue.
Misuse of Authorization Fee
Visa fee ($0.045–$0.09 per occurrence) assessed when an authorization is not followed by a matching clearing transaction within the required timeframe (typically 7 days for most MCCs). Indicates authorizations that were placed but never captured — common in merchants with poor batch discipline or system integration issues. A recurring misuse-of-auth fee pattern is a reconciliation and operational risk flag.
A per-transaction fee from Visa for authorizations that are not matched by a clearing transaction within the required timeframe. Track your auth-to-clear match rate — a declining match rate generates this fee and signals operational problems.
On-Us Transaction
A transaction in which the issuing bank and the acquiring bank are the same institution. The transaction stays "on the books" of a single institution and typically does not route through the card network in the same way — resulting in no interchange fee, reduced scheme fees, and faster settlement. On-us transactions are highly profitable for banks that operate both issuing and acquiring businesses.
When your bank is both the acquirer and the issuer, the interchange flow is internal. On-us transactions often have different economics and no external interchange expense. Ensure your interchange cost model correctly excludes or separately models on-us volume.
PAN (Primary Account Number)
The 13–19 digit card number that identifies the issuer and cardholder account. The first 6–8 digits are the BIN/IIN (Bank Identification Number). The full PAN is a sensitive payment credential governed by PCI DSS — it cannot be stored after authorization without specific tokenization controls. Controllers must ensure that any system storing PANs is in PCI scope and appropriately governed.
The 16-digit card number. PAN data should never appear in your financial reporting systems — only tokenized or masked equivalents. If you see full PANs in GL reconciliation files, you have a PCI DSS scope problem.
PCI DSS
Payment Card Industry Data Security Standard. A set of security requirements mandated by Visa, Mastercard, Amex, Discover, and JCB for any entity handling cardholder data. 12 high-level requirements covering network security, access control, encryption, monitoring, and testing. Non-compliance can result in network fines ($5,000–$100,000/month) assessed to the acquirer and passed to the merchant per MPA terms. Annual QSA assessment required for Level 1 merchants (>6M transactions/year).
Compliance is a cost, not a revenue line. Annual QSA fees, remediation costs, and the potential for non-compliance fines should be budgeted and tracked. Non-compliance assessments from Visa/MC can arrive as scheme fee line items.
Pre-Arbitration
The dispute resolution stage following an unsuccessful representment where the issuer re-challenges the acquirer's evidence before the case escalates to formal network arbitration. In Visa's framework, this is called "Pre-Arbitration" and gives the acquirer a second opportunity to resolve the dispute bilaterally. Accepting a pre-arb typically involves a $500+ processing fee; proceeding to arbitration risks a $250–$500 arbitration fee if the acquirer loses.
The stage before formal network arbitration. Pre-arb has a hard deadline — missing it means automatic loss regardless of the merits. Track pre-arb deadlines as a controlled P&L risk item.
Pre-Authorization / Pre-Auth
An authorization placed for an estimated amount before the final amount is known — common in lodging (hotel check-in), car rental, and restaurant environments. The pre-auth hold reduces the cardholder's available credit but must be followed by a final transaction capture (completion) within the network's tolerance window. Delta between pre-auth amount and captured amount beyond tolerance thresholds triggers interchange downgrade risk.
Creates a balance sheet exposure between auth and capture. The delta between pre-auth amount and final settled amount (tips, fuel pump completions, hotel adjustments) creates a settlement variance that must be reconciled.
Processor / Third-Party Processor
A technology company that processes payment transactions on behalf of an acquiring bank. The processor handles authorization routing, clearing file management, and settlement file generation but typically does not hold a direct network membership — the sponsoring bank does. Examples: Fiserv, FIS, TSYS, Worldpay. Controllers must understand the processor vs. acquirer distinction for revenue recognition (the acquirer is the principal; the processor is often a key vendor whose fees are a direct operating expense).
If your bank uses a third-party processor, settlement data originates there. Your three-way reconciliation (processor data vs. network statement vs. GL) requires a reliable data feed from the processor. Any feed delay is a close risk.
RTP (Real-Time Payments)
The Clearing House's instant payment rail enabling real-time, 24/7/365 credit push payments between US bank accounts. Unlike ACH, RTP transactions settle with immediate finality — no return window, no next-day settlement. Currently capped at $10M per transaction. Growing use in B2B disbursements and merchant funding. Controller implication: RTP-funded positions carry no return risk after posting, simplifying reserve requirements for that funding channel.
Like FedNow — instant settlement eliminates float income. RTP transactions also have different chargeback and dispute mechanics than card transactions. Keep RTP volume and economics separately tracked from card volume.
Residuals
Revenue-sharing payments made by acquirers to ISOs and agents based on the profitability of merchants they introduced. Residuals are typically a percentage of net revenue (MDR minus interchange minus scheme fees) on the ISO's merchant portfolio. From a controller perspective, residuals are a cost of revenue and may require capitalization analysis under ASC 340-40 if they meet the incremental cost of obtaining a contract test.
Monthly revenue share payments to ISO partners. Residuals are a current-period expense that must be accrued at close based on net revenue for the period. Confirm the residual calculation runs on final net revenue, not preliminary.
Same-Day ACH
NACHA rule enabling same-business-day settlement for ACH transactions submitted by network cutoffs (10:30am, 2:45pm, 4:45pm ET). Available for credits and debits. Same-Day ACH has materially changed merchant funding timelines — many acquirers now fund merchants same-day or next-day via Same-Day ACH rather than the traditional T+2 standard ACH cycle. Intraday liquidity implications for the acquirer's treasury function.
Faster DDA funding for merchants. Reduces the settlement receivable holding period on your balance sheet — which is a working capital benefit but also reduces float income if you are FTP-crediting the receivable balance.
SOX (Sarbanes-Oxley Act)
US federal law (2002) establishing internal control requirements for public companies. Section 404 requires management assessment and auditor attestation of internal controls over financial reporting (ICFR). For acquiring controllers at public companies, SOX governs the documentation, testing, and certification of key controls: revenue recognition accuracy, reserve adequacy, scheme fee reconciliation, and settlement account rec. Reserve methodology changes, new revenue streams, and significant accounting estimates all require SOX-quality documentation.
Your control environment. Every significant accounting estimate in acquiring — reserve adequacy, interchange accrual, revenue recognition judgments — requires a documented control. If it is not in the control matrix, it is an audit finding waiting to happen.
Sub-Merchant
A merchant that processes payments under a PayFac's master MID rather than under its own direct acquiring agreement. The PayFac is responsible for the sub-merchant's compliance, chargebacks, and fraud exposure under network rules. Sub-merchants are typically small businesses that benefit from simplified onboarding; they often do not know they are a sub-merchant rather than a direct acquirer customer. Network rules limit sub-merchant transaction volume and geographic scope.
In a PayFac model, the PayFac aggregates sub-merchant activity under its MID. This means your chargeback exposure is concentrated at the PayFac level — a single PayFac failure can generate losses across hundreds of sub-merchants simultaneously.
Surcharging
The practice of adding a fee to card transactions that offsets the MDR. Legal in most US states (prohibited in Massachusetts and Connecticut) following a 2013 settlement with Visa and Mastercard. Network rules strictly govern surcharge disclosures, caps (Visa: capped at the merchant's actual cost of acceptance, max 3%), and applicability (credit cards only — surcharging debit is prohibited under network rules). Controller implication: surcharge revenue is gross revenue; it must be separately disclosed and reconciled.
Surcharging programs shift interchange cost to the cardholder. The accounting treatment depends on whether surcharges are presented gross (revenue with interchange as cost) or net. Confirm with legal and accounting before launching — state law restrictions apply.
Tiered Pricing
MDR pricing model bucketing transactions into 2–4 rate tiers (Qualified, Mid-Qualified, Non-Qualified) with escalating rates. Acquirer controls tier definitions — merchants often face opaque, unpredictable cost structures. Common in legacy community bank and ISO portfolios; being displaced by I++ and flat-rate in modern acquiring. Controller concern: tier reclassification risk (transactions moving from qualified to non-qual) creates revenue uncertainty and is a recurring point in MDR contract disputes.
The hardest pricing model to reconcile. Qualified, mid-qualified, and non-qualified buckets are determined by the processor and not always transparently disclosed. If you offer tiered pricing, audit the qualification rules annually.
VAMP (Visa Acquirer Monitoring Program)
Visa's consolidated monitoring program, which replaced the separate Dispute Monitoring (VDMP) and Fraud Monitoring (VFMP) programs. VAMP measures a count ratio — TC40 fraud plus TC15 disputes divided by settled card-not-present transactions (TC05) — subject to defined exclusions. Where the fact sheet's acquirer-eligibility condition is met, the excessive-merchant threshold is 150 bps effective 1 April 2026 alongside a minimum monthly fraud-and-dispute count for AP, Canada, EU and U.S.; acquirer-level thresholds and other regions differ. Legacy per-dispute fine schedules from the retired programs are not current.
Model it on counts, not dollars — a value-weighted chargeback rate does not approximate VAMP. Exposure begins in the month the threshold is breached, not when the invoice arrives, so build the breach forecast into your monthly close. Take thresholds and assessments from the current published program materials.
Visa Token Service (VTS) / MDES
Network-level tokenization services replacing PANs with network tokens for card-on-file and device-bound transactions. Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) issue tokens that are specific to a merchant-device-account combination. Tokens cannot be used outside their authorized context — dramatically reducing card-on-file fraud. Token-based transactions often qualify for better interchange rates and lower fraud chargebacks.
Token-based transactions require token-to-PAN mapping for chargeback matching. If your dispute management system cannot map tokens back to original transactions, you will have representment failures on tokenized transactions.
Zero-Day Settlement
Settlement of transaction proceeds to the merchant on the same calendar day as the transaction (T+0). Available to select large acquirers and PayFacs with sufficient intraday liquidity facilities. Provides significant working capital benefit to merchants. From an acquirer controller perspective, T+0 settlement requires real-time gross settlement exposure tracking and intraday credit facility management — materially more complex than standard T+1/T+2.
Same-day or immediate settlement to the merchant. Zero float, no FTP income, no settlement receivable. Track zero-day settlement as a separate funding bucket — it changes your balance sheet and FTP income line completely.
Acquirer BIN
The Bank Identification Number assigned to the acquirer by Visa/Mastercard for use in transaction routing and identification. The acquirer BIN appears in authorization messages and settlement files and is used by the network to identify the acquiring institution. A single acquiring bank may have multiple BINs for different product lines, geographies, or subsidiaries. BIN management is an operational function with P&L implications for network fee allocation.
Your bank's BIN is what the network uses to route settlement and billing to you. BIN-level data in network reports must be mapped to your internal entity structure for consolidated reporting. BIN misrouting is rare but creates settlement breaks.
CECL (ASC 326)
Current Expected Credit Loss — FASB's forward-looking credit impairment model replacing the prior incurred loss model. Applicable to financial assets measured at amortized cost including trade receivables, loans, and lease receivables. For acquirers that extend credit to merchants (merchant cash advances, working capital loans, receivables financing) or carry significant merchant receivable balances, CECL requires day-1 recognition of lifetime expected losses. Controllers must build CECL models for qualifying merchant receivable portfolios.
Applies to financial assets measured at amortized cost — not to every balance on the books. Two scope points that matter in acquiring: a merchant reserve is a liability, not an asset needing an allowance; and the settlement receivable is owed by the network, so applying a merchant default rate to it measures the wrong counterparty. Merchant receivables, cardholder receivables and BNPL installment receivables are in scope. Undrawn card availability that is unconditionally cancellable carries no commitment liability. Estimate at each reporting date, not only when stress appears.
Open Banking / PSD2
European Payment Services Directive 2 (PSD2) mandates open access to bank account data and payment initiation by licensed third parties (TPPs). Enables account-to-account (A2A) payments that bypass card networks entirely — no interchange, no scheme fees, real-time settlement. For acquiring controllers, open banking represents a structural threat to card-based MDR revenue long-term, and an emerging alternative payment method that must be accounted for separately from card volume in revenue recognition.
Creates alternative payment initiation outside the card networks. As an acquirer, Open Banking volume bypasses interchange entirely — which is both a cost reduction and a revenue reduction depending on your pricing model.
BNPL (Buy Now Pay Later)
Short-term installment financing offered at point of sale, typically interest-free for the consumer with the merchant paying a higher "merchant discount" (3–6%) to the BNPL provider. From an acquiring controller perspective, BNPL transactions may be processed through existing card rails (virtual card) or through proprietary networks, with different revenue recognition implications. BNPL is a fast-growing payment method requiring specific MDR, reserve, and chargeback treatment in the acquirer's accounting framework.
The accounting model depends entirely on your position: merchant acquirer, issuing bank, or BNPL platform. Each has different revenue recognition, receivable, and reserve treatment. The chapter covers all three.
Dispute / Pre-Dispute (CDRN/RDR)
Visa and Mastercard offer pre-dispute resolution services that intercept disputes before they become chargebacks. Visa's Rapid Dispute Resolution (RDR) and Mastercard's Collaboration for Dispute Resolution Network (CDRN) allow merchants to automatically accept or refund disputes based on rules, preventing escalation to formal chargebacks. Controllers should track pre-dispute resolutions separately from CBs — they have different P&L treatment (refund vs. chargeback) and different reserve implications.
CDRN and RDR are pre-dispute resolution programs that can resolve disputes before they become chargebacks. Merchants enrolled in these programs reduce your chargeback rate and reserve requirement. Track enrollment separately.
Network Operating Regulations
Visa Core Rules, Mastercard Rules — the binding contracts between the card networks and their bank members (issuers and acquirers) that govern every aspect of card acceptance, dispute resolution, interchange, and compliance. Public versions are published annually. Controllers should be familiar with the sections governing dispute resolution timelines, interchange qualification standards, and compliance program fee schedules — violations can create unbudgeted P&L exposure.
The rulebook you are implicitly agreeing to every time you process a transaction. Controllers should read the sections on dispute resolution timelines, interchange qualification, and compliance program fees annually — not just when an auditor asks.
Accrual Basis Revenue
Revenue recognized when earned (performance obligation satisfied) regardless of when cash is received. In payments, this means MDR revenue is recognized at clearing — not at settlement when cash actually moves. The gap between recognized revenue and cash received is the settlement receivable.
The clearing-date revenue accrual is your most material accounting estimate every close. Confirm the data feed from your processor to the GL captures clearing date, not settlement date or batch date.
Adverse Action / Credit Decision
A formal decline decision on a merchant application or reserve increase that triggers regulatory notification requirements under ECOA and the Fair Credit Reporting Act. Relevant when the acquirer makes credit-based decisions about merchant reserves or approval.
If your reserves team increases a merchant reserve for credit reasons, ensure the notification workflow is in place. Failure to provide adverse action notices creates regulatory exposure that lands in your risk environment.
Auth Rate
The percentage of authorization requests that result in an approval. A declining auth rate on an existing merchant portfolio can signal card issuer friction, merchant fraud deterioration, or card data quality problems — all of which affect future revenue.
Auth rate is a leading indicator of revenue. A 1% decline in auth rate on a $500M GPV merchant is $5M of transactions that do not clear, do not settle, and do not generate revenue. Track auth rates monthly by merchant segment.
Bank Identification Number (BIN) Sponsorship
When a smaller institution or fintech uses a larger bank's BIN to access network rails. The sponsoring bank bears regulatory and network compliance liability for the sponsored entity's activity. Common in embedded payments and fintech partnerships.
BIN sponsorship arrangements require careful contract review — the sponsoring bank often retains liability for chargebacks, compliance fines, and network violations generated by the sponsored entity. Understand the indemnification structure before booking revenue from these relationships.
Cardholder Data Environment (CDE)
The people, processes, and technology that store, process, or transmit cardholder data. PCI DSS compliance requirements apply to the CDE. Scope reduction (removing systems from the CDE through tokenization or point-to-point encryption) reduces compliance cost and audit burden.
CDE scope directly affects your PCI compliance budget. If engineering reduces scope through tokenization, your annual QSA assessment cost decreases. Track scope changes and their compliance cost impact — this is a real P&L lever.
Chargeback-to-Transaction Ratio (CTR)
Monthly chargeback count divided by monthly transaction count, expressed as a percentage. The primary Visa and Mastercard compliance monitoring metric. Thresholds: Visa Early Warning >0.65%, Standard Program >0.9%. Mastercard >1.0% triggers monitoring.
CTR breaches generate compliance program fees that are not in most budgets. Build CTR monitoring into your monthly close package with a traffic-light signal. A merchant approaching 0.65% needs a management conversation, not just a data note.
Commercial Card
Corporate, purchasing, fleet, and business credit cards. Typically carry significantly higher interchange rates (2.5%+ for purchasing cards) but can qualify for lower rates with Level 2/3 data. Require specific authorization and settlement data fields for optimal interchange.
Commercial card interchange is the single largest interchange optimization opportunity for B2B-heavy acquirers. If your merchant base includes large buyers, the delta between unoptimized and Level 3-qualified commercial interchange can be 80+ bps — track it.
Concentration Risk
The exposure created when a small number of large merchants represent a disproportionate share of GPV, revenue, or chargeback exposure. If one merchant represents >10% of portfolio GPV, their failure or departure creates a material P&L event.
Run a concentration analysis every close. The top 10 merchants by GPV, revenue, and reserve balance should each have a risk flag that shows what their departure would mean to the P&L. This belongs in the management report, not just the risk report.
Contra-Revenue
A deduction from gross revenue presented on the face of the income statement rather than as an expense. Rewards program costs, refunds, and certain volume rebates may be classified as contra-revenue under ASC 606 depending on whether they represent a payment to a customer.
The gross revenue vs. contra-revenue classification affects your top-line presentation but not operating income. Management tends to focus on the revenue number — be clear in your bridge about what is a contra-revenue item vs. an expense item, and document the ASC 606 basis.
Cross-Border Fee
A fee charged by Visa or Mastercard on transactions where the card is issued in a different country than the merchant location. Typically 0.40%-0.90% assessed on the acquirer, often passed through to merchants. Separate from the DCC margin.
Cross-border fees accrue on volume that has nothing to do with your pricing decisions — they are driven by your merchants' customer geography. Track international mix as a standalone metric. Growing international mix means growing scheme fee cost even if your domestic economics are stable.
Days Sales Outstanding (DSO)
Settlement receivables divided by daily net revenue. Measures how many days of revenue is sitting in the settlement receivable on the balance sheet at any point. In acquiring, DSO is typically 1-3 days but can spike with funding holds or processor delays.
A rising DSO that is not explained by changed settlement timing is a warning sign — either revenue recognition is running ahead of cash collection, or there is a merchant funding hold creating a balance sheet build. Reconcile DSO weekly during close.
Effective Interchange Rate
Total interchange expense divided by total settled volume, expressed in basis points. The blended interchange rate actually paid across all card types, MCCs, and qualification levels. The most useful single metric for tracking interchange cost trends.
Your effective interchange rate will drift over time as card mix, qualification rates, and network rate changes interact. Model the effective rate separately from the published rate. A rising effective rate with flat pricing means margin compression is coming if you cannot pass it through.
Embedded Finance
The integration of financial services — payments, lending, insurance — directly into non-financial software platforms. In payments, embedded finance means SaaS companies, marketplaces, and vertical software vendors becoming the distribution channel for payment acceptance.
Embedded finance partnerships often use revenue share structures where the platform takes a cut of the acquiring economics. Your revenue share accrual model must be calibrated to each platform's contract terms, volume trajectory, and payment timing.
Excessive Chargeback Program (ECP)
Visa's tiered compliance program for acquirers whose merchants breach chargeback thresholds. Generates monthly program fees assessed directly against the acquirer, escalating over time if merchants remain in breach.
ECP fees are not in most people's budget because they arrive without warning in the network billing statement. Build a forward-looking ECP fee estimate into your scheme fee accrual whenever you have merchants approaching chargeback thresholds.
Float Income
Interest or FTP credit earned on funds held during the settlement cycle. The average daily settlement float balance (daily GPV times settlement lag days) multiplied by the FTP rate is the float income for the period. A significant but often invisible P&L contributor.
Float income moves with interest rates and GPV simultaneously. When rates rise, float income improves. When GPV grows, float income grows. When instant settlement expands, float income shrinks. Model all three variables in your annual budget. See the FTP tool in Controller Tools.
Funding Hold
A temporary delay in merchant settlement beyond normal timing, triggered by fraud risk, dispute velocity or compliance review. A hold does not increase the settlement receivable — the network has already settled with you. It retains cash while the corresponding merchant payable stays outstanding.
Get the balance-sheet effect right: holding funds means more cash and an undischarged payable to the merchant, not a larger network receivable. The converse also holds — funding a merchant early does not remove the network receivable; it consumes cash and creates a financing need while that receivable remains open. Confirm the exposure being managed is covered, and document the hold decision and expected release date.
Interchange Optimization
The process of reducing interchange cost by improving transaction data quality, routing, and qualification. Includes passing Level 2/Level 3 data, reducing downgrades, optimizing authorization practices, and ensuring correct MCC assignment.
Interchange optimization is one of the few acquirer cost lines you can directly influence. Track downgrade rate, Level 2/3 qualification rate, and EIRF volume monthly. A 5bps improvement in effective interchange rate on $10B GPV is $5M of annual cost savings.
Issuer Hold
A temporary hold placed by the card-issuing bank on settlement funds during a dispute or investigation. Different from an acquirer funding hold — in an issuer hold, the network is directing funds to be held pending dispute resolution.
Issuer holds can create unexpected settlement receivable aging. If holds are material, flag them in the close package as a timing item — they are not losses, but they age the receivable and could look like collection risk if unexplained.
Net Revenue Per Transaction
Total net revenue divided by total transaction count. Captures the blended economics per transaction across all pricing models, merchant segments, and fee types. A useful supplement to take rate when comparing high-ticket vs. low-ticket merchant portfolios.
Take rate can be stable while net revenue per transaction falls if average ticket size is declining. Monitor both metrics. A shift toward smaller-ticket, higher-frequency merchants can maintain take rate while compressing absolute economics per transaction.
Network Access and Brand Usage Fee (NABU)
Visa's per-transaction fee for network access and brand usage, charged to the acquirer on every cleared transaction regardless of amount. Distinct from the assessment fee (which is volume-based). Small per-item but adds up at scale.
NABU does not scale with transaction value — it scales with count. High-frequency, low-ticket merchants (QSR, transit, parking) generate disproportionate NABU cost relative to their GPV contribution. Model NABU using transaction count, not just volume.
Payment Facilitator (PayFac) Model
A payment acceptance model in which a master merchant (the PayFac) aggregates sub-merchant activity under its own MID and assumes liability for all sub-merchant transactions. The PayFac is responsible for sub-merchant underwriting, compliance, and dispute management.
PayFac master merchant accounting requires consolidating sub-merchant activity that may span thousands of small businesses. Your reserve model must account for portfolio-level loss rates, not individual sub-merchant rates. Chargeback exposure is highly concentrated and correlated in a PayFac failure scenario.
Qualified Rate
The lowest interchange tier in a tiered pricing model, applied when a transaction meets all qualification criteria (card-present, swiped/dipped, settled same day). Most transactions at well-run merchants should qualify at this rate — significant downgrade from qualified to mid- or non-qualified signals process issues.
Track the qualified rate percentage month over month. A declining qualified rate without a corresponding change in merchant mix or card type is usually an operational problem — authorization timing, batch cut-off compliance, or data field quality.
Rolling Reserve Release
The scheduled return of funds from a rolling reserve to a merchant after the required holding period (typically 180 days). Releases are income-neutral — the liability arose when the reserve was withheld from merchant settlement, with no expense at inception. Release discharges that obligation (ASC 405-20-40-1); it is not a P&L event. Tracking release schedules is a cash flow and balance sheet management function.
Maintain a rolling reserve release schedule by merchant as a balance sheet management tool. Failing to release on schedule is a merchant services liability. Over-releasing (releasing before the chargeback window is closed) is a risk management failure. Both are controller problems.
Scheme Fee True-Up
The adjustment posted when actual Visa or Mastercard billing arrives and differs from the accrual estimate. If the accrual was lower than actual, a debit true-up hits the current period. If higher, a credit. The magnitude of true-ups is a direct measure of accrual model accuracy.
Track your true-up as a percentage of the prior-month accrual every close. If it consistently runs >3%, your accrual methodology needs recalibration — you are systematically under- or over-accruing. The scheme fee accrual tool in Controller Tools is designed to reduce this variance.
Underwriting
The process of evaluating merchant credit risk before onboarding. Acquirers underwrite merchants against potential chargeback losses, fraud exposure, and the risk of merchant insolvency creating an unrecovered debit balance. The outcome of underwriting determines reserve requirements and funding terms.
The controller interface with underwriting is the reserve requirement — underwriting determines how much reserve is required, but you own the accounting for it. Ensure reserve amounts determined in underwriting match what is actually funded and tracked on the balance sheet.
Volume Incentive / Network Incentive
Credits or rebates offered by Visa or Mastercard to high-volume acquirers in exchange for volume commitments or market share growth. Typically structured as quarterly or annual credits against scheme fee expense. Material for large acquirers and often subject to variable consideration treatment under ASC 606.
Volume incentives are often multi-year, threshold-based, and subject to clawback if volume commitments are missed. Under ASC 606 variable consideration, you must estimate the likely threshold achievement and constrain the recognized amount to what is highly probable. Do not front-load the full annual incentive in Q1.
About This Guide · Disclaimer
This handbook was written by Nico Rivera, drawing on direct operational experience in merchant acquiring finance — revenue recognition, fee analysis, reserves, close & reconciliation, FX exposure, scheme economics, and pricing and margin analysis.

Educational Use Only. This content is published for educational and general informational purposes. It is based on generalized industry concepts, publicly available accounting standards, and controller-style analysis of the acquiring business. It does not include proprietary company information, confidential operating data, internal systems documentation, or internal accounting policies from any employer, past or present.

Accounting conclusions, revenue classification decisions, reserve methodologies, and financial statement disclosures vary by company, contract terms, auditor view, fact pattern, and interpretation of applicable GAAP. Nothing here constitutes legal, tax, accounting, investment, regulatory, or compliance advice. Readers should consult their own accounting policy, legal, tax, audit, and compliance teams before relying on any specific treatment.

This guide represents the author's independent views and does not represent the views of any employer, past or present.

Sister sites: See also controllerpm.com for project economics and management finance, liquiditycontroller.com for treasury and liquidity management, and theagenticcontroller.com for AI-driven finance and the future of the controller function.

For sourcing detail, author attestation, and audit support contact, see Sources & Attestation.

© 2026 Nico Rivera. All rights reserved.
Chapter 09

The Close
Playbook

Variance analysis against volume and rate drivers, network quarterly billing in arrears, the full month-end close operating model, and the failure scenarios that blow up a clean close.

The acquiring close is not a general ledger exercise — it is a volume and rate reconciliation. Every line on the P&L is the product of a volume driver (GTV, transaction count, card mix) and a rate driver (MDR bps, interchange rate, scheme fee rate). When actual results deviate from plan, the explanation is always one of those two dimensions. The controller who understands this structure can produce a fully explained variance in hours. The one who doesn't spends days chasing unexplained noise.

The second structural reality of the acquiring close is billing in arrears. Visa and Mastercard do not bill scheme fees in real time. The Consolidated Billing Statement (CBS) and Mastercard Consolidated Billing System (MCBS) arrive 15–30 days after month-end. Some network fee categories — particularly FANF, cross-border assessments, and integrity fees — are billed on a quarterly lag. A controller who books only what has been billed is systematically understating costs and overstating margin every single period.

The Volume × Rate Decomposition Framework

Every variance in acquiring revenue or cost can be decomposed into a volume effect and a rate effect. This is the margin bridge. Build it into your close process and you will never present an unexplained variance to leadership again.

Variance Decomposition — Revenue Bridge
Actual Revenue = Actual GTV × Actual MDR Rate
Budget Revenue = Budget GTV × Budget MDR Rate

Volume Effect = (Actual GTV − Budget GTV) × Budget MDR Rate
Rate Effect    = (Actual MDR Rate − Budget MDR Rate) × Actual GTV
Total Variance = Volume Effect + Rate Effect

Example: Actual $102M GTV at 2.25% MDR vs. Budget $100M at 2.30% MDR
Budget Revenue = $2,300,000   ($100M × 2.30%)
Actual Revenue = $2,295,000   ($102M × 2.25%)
Volume Effect = ($102M − $100M) × 2.30% = +$46,000 (favorable)
Rate Effect    = (2.25% − 2.30%) × $102M = −$51,000 (unfavorable)
Net Variance = −$5,000 ✓ ($2,295K − $2,300K)
Interchange Cost Variance Bridge — Two-Factor (exact)
Volume Effect = (Actual GTV − Budget GTV) × Budget blended IC rate
Rate Effect    = (Actual blended IC rate − Budget blended IC rate) × Actual GTV

Volume + Rate = Actual cost − Budget cost, exactly.

This bridge is complete. Card mix is already inside the rate effect, because
a mix shift is one of the things that moves the blended rate.
Do Not Add a Mix Line to a Complete Rate Effect
A mix effect computed as Actual GTV × (blended rate at actual mix − budget blended rate) is not a missing fourth component. On a two-factor bridge it is the same quantity as the rate effect, or a large part of it — adding it makes the bridge over-explain the variance and stop reconciling. The bridge then fails to tie, and the usual response is to plug the difference into "other," which buries the real driver.

Mix genuinely is the story behind many interchange variances — a shift from regulated debit to rewards credit raises blended cost with no change in GTV or MDR. The question is not whether to talk about mix, but whether to add it. Two valid ways to present it:

Option 1 — keep the exact two-factor bridge and explain mix within the rate line: "rate effect −$X, of which roughly −$Y is card-mix shift." Nothing is added; the narrative decomposes the rate effect rather than supplementing it.
Option 2 — split rate and mix formally using a consistent sequential-weighting convention so the three factors still sum exactly to the total variance. Mix must replace part of the rate effect, not sit alongside it.
Three-factor, with the rate/mix interaction assigned to mix.
V = volume, mᵢ = category share, rᵢ = category all-in rate; A = actual, B = budget.

Volume = (V_A − V_B) × Σ(m_Bi × r_Bi)
Rate    = V_A × Σ[m_Bi × (r_Ai − r_Bi)]
Mix     = V_A × Σ[(m_Ai − m_Bi) × r_Ai]

Volume + Rate + Mix = Actual cost − Budget cost ✓

Requires category shares to sum to 1 and consistent treatment of per-item fees.
Other conventions are acceptable provided they reconcile exactly. The test is not which formula you prefer — it is whether the components sum to the actual variance without a plug. Verify that before the bridge goes in a deck.
Independent algebraic verification; ASC 250-10-20 (calculation errors) where the bridge supports financial reporting.

Network Billing in Arrears — The Controller's Timing Problem

Scheme fees are not paid in real time. They are billed on a lag that creates a structural accrual requirement every single month. Failing to understand the billing cycle of each fee category is the #1 source of scheme fee accrual variances at close.

Fee CategoryNetworkBilling FrequencyLagAccrual Approach
Acquirer Assessment (0.13%)VisaMonthly~20 daysAccrue monthly using volume × rate
NABU / APF (per item)VisaMonthly~20 daysAccrue monthly using transaction count × rate
FANF (Fixed Acquirer Network Fee)VisaMonthly~20 daysAccrue based on MID count × tier rate — critical to track tier changes
ISA (International Service Assessment)VisaMonthly~20 daysAccrue using cross-border volume × ISA rate
Misuse of Authorization FeeVisaMonthly~20 daysEstimate from daily auth monitoring; reconcile to billing
Acquirer AssessmentMastercardMonthly~20 daysAccrue monthly using volume × rate
Network Access Fee / NABU equiv.MastercardMonthly~20 daysTransaction count × rate
Cross-Border FeesVisa / MCMonthly~20 daysAccrue from cross-border volume file daily
Digital Enablement Fee / Token FeesVisa / MCQuarterly30–45 days post-quarterAccrue monthly (1/3 of quarterly estimate); true-up at receipt
Network Integrity / Compliance FeesVisa / MCQuarterly30–45 days post-quarterAccrue monthly based on known violations; spike-risk at Q-end
Network monitoring assessments (VAMP / ECP / EFM)Visa / MCMonthly~30 daysAccrue if any enrolled merchants; escalate to risk team
PCI Non-Compliance FinesVisa / MCMonthly / Ad hocVariableAccrue when merchant notified of non-compliance; document ASC 450 basis
Quarterly Billing in Arrears — The Hidden Close Risk
Some network fees are billed on a quarterly or other non-monthly cycle while the underlying obligation is incurred continuously. Accruing only when billed understates the intervening months and lumps the cost into whichever month the invoice lands.

Accrue for the obligation incurred, less what is already booked. Each month: estimate the obligation arising from that month's qualifying activity, subtract amounts already recorded for the period, and book the difference. Reconcile to the actual invoice when it arrives and true up.

Equal thirds are a simplification, not the method. Dividing a quarterly estimate by three is appropriate only where the obligation actually accrues evenly. If the fee is volume-driven and volume is seasonal — and in acquiring it usually is — equal thirds will be wrong every quarter, most visibly in Q4. Drive the accrual from the same base the fee is assessed on (eligible volume, transaction count, active MIDs) rather than from the calendar.

A quarterly lag does not itself create a Q4 spike. A fee billed one quarter in arrears is still one invoice per quarter, arriving a quarter late. Several quarters arriving together indicates a billing or onboarding anomaly, not the normal operation of a quarterly cycle. If your model predicts a structural Q4 pile-up, check whether you are modeling the billing calendar or a backlog.

Control: maintain an effective-dated billing calendar by network fee code — cycle, assessment basis, lag, and applicable effective date — and re-verify it against the current network billing resources on each release. Fee cycles and bases differ by code and change; a single "quarterly, divide by three" rule applied across codes will be wrong for some of them. Document the estimation methodology in a recurring accrual memo. Auditors will ask.
ASC 450-20-25-2 for contingent assessments. Fee specifics: current network billing resources — Visa Core Rules §1.11.1; Mastercard Security Rules and Procedures §8.3.

The Controller's Daily Operating Rhythm

This is what the job actually looks like. Not theory — the specific tasks a payments controller executes every business day to run a clean acquiring book. If you're not doing all of these, you're flying blind.

TimeTaskTool / SourceWhat You're Looking For
MorningPull yesterday's clearing and settlement filesNetwork portal / SFTPTransaction count, gross volume, net settlement amount
MorningConfirm net settlement received in bank accountBank statement / treasury systemNet settlement ± $10K of file. Any break >$10K = same-day escalation
MorningCheck open settlement receivables agingGL subledgerAny receivable open >3 business days requires explanation before 9am
Mid-dayReview merchant funding confirmationsFunding system / ACH logAll funded merchants received correct net amount. Reserve holds applied correctly.
Mid-dayScan chargeback queueCB tracking systemAny new CBs for top-50 merchants by exposure. Any merchant hitting 0.40% CB rate.
End of dayUpdate interchange cost trackerSettlement file + rate modelActual blended IC rate vs. budget. Any shift >3 bps requires card mix analysis.
End of dayAuth-to-clear conversion rate checkProcessing systemYesterday's auth count vs. today's cleared count for same-day merchants. Flag <95%.
WeeklyScheme fee accrual updateVolume report + accrual modelMTD accrual on track with actual volume. Quarterly fee 1/3 estimate current.
WeeklyReserve adequacy spot check — top 20 merchantsReserve system + CB agingCoverage ratio >0.80x for all top-20. Any merchant below triggers same-week assessment.
WeeklyVariance flash: actual GTV vs. budget paceProcessing system + budget modelAre we on track? Volume effect and rate effect calculated. Explanation ready for Friday business review.
The 15-Minute Daily Discipline
The best payments controllers spend 15 minutes every morning running the above checks before anything else. Not because the business will break if they don't — but because the problems that do break the business are always found in these 15 minutes, not during the month-end close. A settlement receivable left open for 5 days without investigation is a $500K problem waiting to be discovered. Caught on day 3, it's a 5-minute escalation email.

Month-End Close Checklist — Acquiring Controller

DayTaskSource of TruthOwnerRisk if Missed
M+1Final settlement rec — last business day of monthNetwork clearing/settlement files + bank statementSettlement OpsOpen receivable on balance sheet
M+1Cutoff: pull cleared transaction file for last calendar day; lock revenueProcessing systemControllerRevenue in wrong period
M+2Revenue accrual — any late-clearing transactions with clearing date in periodRevenue subledgerControllerUnderstated revenue
M+2Interchange cost accrual — network settlement file total vs. prior billingNetwork settlement fileControllerUnderstated COGS; margin overstated
M+2Variance flash: actual GTV vs. budget; actual MDR rate vs. budget rateProcessing system + budget modelController / FP&AUnexplained variance to leadership
M+3Scheme fee accrual — monthly fees (assessment, NABU, APF, ISA, FANF)Prior CBS/MCBS + current volumeControllerUnderstated scheme expense
M+3Quarterly fee accrual — 1/3 of tokenization, integrity, compliance estimatesPrior quarterly billings + volume trendControllerSystematic Q4 spike; possible restatement
M+4Reserve roll-forward: opening balance + withheld − released − applied to CBsReserve systemController / RiskMisstated reserve liability
M+4ASC 450 assessment — specific merchant loss accruals (probable + estimable)CB aging + risk watchlistController / RiskUnderstated contingent liability
M+5FX remeasurement — open FX-denominated receivables and payablesBalance-sheet-date FX ratesController / TreasuryMisstated P&L and balance sheet
M+5Card mix analysis — actual vs. budget; compute rate effect on IC costNetwork settlement detail by BINControllerInterchange variance unexplained
M+6GL subledger tie-out — all accounts reconciled with supporting detailGL systemControllerAudit finding; balance sheet unsupported
M+7Full variance bridge: revenue (volume / rate / mix), IC cost, scheme fees, marginGL + budget + prior periodController / FP&ACannot explain results to leadership
M+8Management P&L package — flash results with bridge narrativeGLControllerLeadership operating blind
M+10Scheme billing receipt — true-up monthly fee accruals line by lineVisa CBS / MC MCBSControllerOverstated or understated accrual
Q+45Quarterly fee billing receipt — true-up tokenization / integrity accrualsQuarterly network billing statementController3-period cumulative accrual error
M+15Final close certification — SOX sign-off; all recs filedAll aboveController + CAOSOX deficiency

Building the Acquirer Margin Bridge

The margin bridge is the most important deliverable the acquiring controller produces each month. It explains, in dollar terms, every driver of the change in net margin versus plan and versus prior period. Leadership does not want to hear "volume was up" — they want to know exactly how much each driver contributed and why.

Monthly Margin Bridge — $100M Portfolio Example
BUDGET $500K 50 bps +$46K Vol ↑ carry −$51K Rate ↓ carry −$35K Mix IC cost ↑ carry −$12K Scheme carry ACTUAL $448K 44 bps Budget $500K + Vol $46K − Rate $51K − Mix $35K − Scheme $12K = Actual $448K

Accrual Principles — Four Rules

Failure Scenarios — What Breaks the Close

Close Risk #1 — Settlement Delay
What happens: Network processing delay. Settlement funds arrive T+3 instead of T+1. Receivable sits open.
P&L impact: None if temporary — receivable clears when cash arrives. But a cash shortfall may require drawing the credit facility, creating unbudgeted interest expense.
Control: Monitor open settlement receivables daily. Any open position >3 business days escalates to network relations and treasury immediately.
Close Risk #2 — Card Mix Shift (Interchange Spike)
What happens: A large merchant's card mix shifts to rewards/corporate cards. Interchange cost spikes 40–60 bps on affected volume with no MDR change.
P&L impact: On $10M affected volume, 50 bps shift = $50K unbudgeted margin compression. Invisible in a two-line variance unless you decompose the mix effect.
Control: Run interchange cost as % of GTV by merchant segment weekly. A variance >5 bps from the prior week triggers a card mix analysis before close.
Close Risk #3 — Quarterly Network Fees Spike at Q4
What happens: Controller has only been accruing monthly fees. Quarterly digital enablement and compliance fees arrive in Q4 billing covering Q2–Q4 adjustments. Single month absorbs 6+ months of costs.
P&L impact: Q4 scheme expense materially overstated; Q1–Q3 understated. Material misstatement risk if the quarterly amounts are significant.
Control: Build a quarterly fee accrual model separately from the monthly model. Use prior-year quarterly billings as the base; adjust for volume growth. Reconcile each billing to the quarterly model and investigate variances >10%.
Close Risk #4 — Reserve Under-Accrual
What happens: High-risk merchant spikes chargebacks late in the month. Controller hasn't run an ASC 450 assessment yet.
P&L impact: Material loss accrual required at close. If missed, out-of-period adjustment or restatement required.
Control: Weekly chargeback aging and reserve adequacy check for the top 50 merchants by CB exposure. Never discover a $2M shortfall at month-end.
Close Risk #5 — Late Presentments
What happens: A merchant clears 90-day-old transactions in a single batch. Revenue and interchange hit the current period while the underlying merchant sales are old. Volume spikes with no corresponding current-month business.
The tempting conclusion, and why it is usually wrong: that revenue is overstated now and understated then, requiring a prior-period allocation. Late presentment by itself does not establish a prior-period error. Ask when your performance obligation was satisfied — the processing service is performed when the transaction is processed and cleared, which is now. The merchant's sale to its own customer happened 90 days ago, but that is the merchant's revenue event, not yours. Recognizing processing revenue in the current period is generally correct here, and backdating it substitutes the merchant's revenue timing for your own.
When it genuinely is a prior-period issue: where the facts show your service was satisfied in the earlier period and simply went unrecorded — a clearing file received and processed before period end but never posted, for example. That is an error under ASC 250. The test is the recognition facts, not the age of the underlying sale.
P&L impact: whether or not any period is adjusted, the current period carries volume that will not repeat. Flag it in the variance narrative so the spike is not read as demand — the margin is real, the run-rate implication is not.
Control: monitor the auth-to-clear lag distribution daily and flag clearing well outside its normal range. Late presentments also risk interchange downgrade, compounding the cost impact. Document the recognition conclusion for any material late batch before close, rather than defaulting to a period reallocation.
ASC 606-10-25-23 through 25-30; ASC 250-10-45-23.

Month-End Close Journal Entries — Complete Set

M+1 through M+15 — Every Entry a Controller Books
M+1 — Revenue cutoff accrual (cleared but not yet settled, last 2 days):
2/30 of the Scenario A portfolio = $6,666,667 of GTV. Fees net withheld.
Dr Settlement Receivable              $6,564,667  ($6,666,667 − $93,333 − $8,667)
Dr Interchange Expense                 $93,333    (1.40%)
Dr Scheme Fee Expense                   $8,667     (0.13%)
  Cr Merchant Payable                     $6,550,000  ($6,666,667 − $116,667)
  Cr MDR Fee Revenue                     $116,667   (1.75%)
Dr = $6,666,667 · Cr = $6,666,667 ✓ · margin $14,667 (22 bps)

M+3 — Monthly scheme fee accrual — unrecorded fees only:
Dr Scheme Fee Expense — Monthly      $121,333  ($130,000 month − $8,667 already in the M+1 entry)
  Cr Scheme Fee Accrual Payable          $121,333

M+3 — Quarterly network fee accrual:
Dr Scheme Fee Expense — Quarterly     $30,000    (estimate of the obligation incurred this month)
  Cr Scheme Fee Accrual — Quarterly      $30,000

M+4 — Reserve roll-forward (monthly withholding net of releases and CBs):
Dr Merchant Payable                      $10,000,000  (monthly withheld from funding)
  Cr Merchant Reserve Liability            $10,000,000
Dr Merchant Reserve Liability            $9,700,000   (prior 90-day reserve released)
  Cr Merchant Payable / Cash               $9,700,000

Note: the M+1 cutoff already expensed $8,667 of scheme fees for the last two
days, so the monthly accrual books only the remainder. See the control below.


M+5 — FX remeasurement (EUR settlement receivable at period-end rate):
Dr FX Loss                                 $17,000
  Cr Settlement Receivable (EUR)          $17,000    (€1M × rate movement 1.0820 → 1.0650)

M+10 — Scheme fee true-up when CBS/MCBS received:
Dr Scheme Fee Accrual Payable           $2,600     (over-accrued: actual $127,400 vs. $130,000)
  Cr Scheme Fee Expense                    $2,600

M+10 — New fee category discovered in billing:
Dr Scheme Fee Expense                     $4,500     (Network Integrity Fee — not in prior model)
  Cr Scheme Fee Payable                     $4,500     → Add to next month accrual model
The Cutoff Entry and the Monthly Accrual Overlap — Book Each Fee Once
The cutoff entry at M+1 and the monthly fee accrual at M+3 both touch scheme fees for the same period, and the natural reading — full month at M+3, plus the cutoff at M+1 — expenses the last two days twice. Total scheme expense for the month is $130,000 however it is split; if your entries sum to $138,667 the cutoff has been double-booked.

Book the accrual net of what is already recorded: monthly obligation less amounts already expensed = $130,000 − $8,667 = $121,333. Run the same subtraction for interchange, which the cutoff also expensed.

Then reconcile the fee populations. The cutoff entry above deducts scheme fees from the settlement receivable, which is the net-withheld model; the monthly accrual raises a payable, which is the separately-billed model. Both can be correct only if they cover different fee categories — some fees are withheld in settlement, others invoiced on the billing cycle. Maintain the fee-category inventory from Chapter 2 and confirm no category appears in both populations. If a fee is netted from the receivable and carried as a payable, the same cost has been recorded twice and the payable will never clear.

Control: tie total monthly interchange and scheme expense across all entries back to a single independently computed monthly figure before close. Entry-by-entry review will not catch this — only the total will.
ASC 606-10-32-2; ASC 250-10-20 (calculation errors).

Month-End Close Checklist — M+1 to M+15

Complete Month-End Close Checklist — Acquiring Controller
M+1:
□ Cleared transaction file locked — all clearing dates in period identified
□ Revenue cutoff accrual booked for cleared-not-yet-settled transactions
□ Settlement receivable aging reviewed — no open items >3 days without explanation

M+2:
□ Full month interchange expense reconciled to network settlement file total
□ MDR revenue reconciled to processing system cleared volume × MDR rate
□ Variance flash prepared: actual GTV vs. budget, actual MDR bps vs. budget

M+3:
□ Monthly scheme fee accrual booked (assessment, NABU, APF, FANF, ISA)
□ Quarterly scheme fee accrual booked (1/3 of quarter estimate)
□ Reserve roll-forward balanced: Opening + Withheld − Released − Applied = Closing
□ ASC 450 assessment run for all merchants with CB rate >0.50% or coverage <0.80x

M+5:
□ FX remeasurement completed — all FX-denominated monetary items at period-end rate
□ Card mix analysis run — actual blended IC rate vs. budget (flag >5 bps variance)

M+6:
□ GL subledger tie-out complete — every account balance supported by detail
□ Merchant payable balance = only unfunded amounts (zero if all merchants funded)

M+7:
□ Variance bridge complete: Volume + MDR Rate + IC Mix + Scheme = Total margin variance
□ Management P&L package prepared with narrative

M+10:
□ CBS (Visa) and MCBS (Mastercard) received and every line item reconciled to accrual
□ True-up journal entries posted — over/under accrual by fee category documented
□ Any new fee categories flagged and added to next month's accrual model

M+15:
□ All reconciliations signed off and filed
□ All open items resolved or formally documented with escalation
□ SOX close certification completed — controller and CAO attestation
🔍 Controller Lens — Month-End Close
WHAT ARE YOU CERTIFYING?That every P&L line is supported by a sub-ledger, every balance sheet account has detail, every accrual has a documented methodology, and every variance has a narrative. The close certification is your professional attestation — not an administrative checkbox.
SOURCE OF TRUTH HIERARCHYNetwork settlement file → Processing system → GL subledger → GL balance → Bank statement. If any link in this chain breaks, you don't have a close. You have an estimate dressed up as a close.
TIMING SEQUENCERevenue (M+1) → Accruals (M+3) → Reserve (M+4) → FX (M+5) → Subledger (M+6) → Bridge (M+7) → Billing true-up (M+10) → Certification (M+15). Miss any step and the close is open whether you've signed it or not.
KEY RISKThe close that looks clean and isn't. Scheme fee accrual with wrong volume base. Reserve with no sub-ledger. Revenue in the wrong period. These don't show up until the auditor asks a question you can't answer. The checklist exists to ask those questions first.
Chapter 10

Controller KPIs &
POS Terminal Accounting

The metrics dashboard every acquiring controller must own, float economics, and the definitive accounting treatment for POS terminal rental vs. sale — an area where most acquirer finance teams get it wrong.

The Controller's KPI Dashboard

These are the metrics that tell you whether the acquiring business is performing as modeled. A controller who can't speak to all of these at a weekly business review isn't functioning as a strategic finance partner — they're a scorekeeper. Know these cold. Know what drives them. Know what their movement signals before it shows up in the P&L.

KPIFormulaTarget / BenchmarkController Alert Threshold
Net Take Rate (bps)(MDR Revenue − Interchange − Scheme Fees) / GTV × 10,00030–70 bps (SMB); 12–30 bps (enterprise)>5 bps variance from prior month unexplained
Gross Take Rate (bps)MDR Revenue / GTV × 10,000175–250 bps blendedDecline >10 bps MoM (pricing pressure / mix shift)
Interchange Cost %Interchange Expense / GTV × 1001.40–1.70% blended US portfolio>5 bps increase (card mix shift / downgrade spike)
Scheme Fee Rate (bps)Scheme Fees / GTV × 10,00010–18 bps typicalNew fee line items; >2 bps MoM variance
Chargeback Rate (%)CB Count / Transaction Count × 100<0.50% healthy; 0.65% = Visa warningAny merchant approaching 0.50%; portfolio >0.30%
Reserve Coverage RatioReserve Balance / 90-Day CB Exposure>1.0x (fully covered)<0.80x triggers review; <0.60x triggers accrual assessment
Settlement Break RateOpen Settlement Items / Total Settlement Items<0.01% by countAny break >$100K open >3 days; any break >5 days regardless of amount
Downgrade Rate (%)EIRF + Standard Volume / Total Volume × 100<2% healthy; <5% acceptable>5% triggers data quality / merchant operations review
FX Exposure (open)Foreign-currency receivables + payables at spot rateDepends on hedge policyAny unhedged position >$1M in a single currency
Float DaysAvg days between clearing and merchant DDA funding1.0–1.5 days>2.0 days signals operational delay or funding backlog
Revenue Leakage (%)(Expected MDR − Billed MDR) / Expected MDR × 100<0.5%>1% triggers pricing/billing system audit

Float Economics — The Hidden P&L Line

Float is the time value benefit the acquirer captures between receiving settlement funds from the network and disbursing those funds to the merchant's DDA. In a $100M/month portfolio with a 1.5-day average float, the acquirer holds approximately $5.0M in investable float on any given day ($100M ÷ 30 days × 1.5). At a Fed Funds rate of 4.50%, that float generates approximately $225K/year in interest income — a real, trackable P&L line that most mid-market acquirer controllers never model.

Float Revenue Calculation
Average investable balance = Monthly GTV / 30 × Average float days
= $100,000,000 / 30 × 1.5 = $5,000,000

Interest for a period = Average balance × Annual rate × Days / 365
Full year: $5,000,000 × 4.50% × 365/365 = $225,000
One month: $5,000,000 × 4.50% × 30/365 = $18,493

Float sensitivity: +1 day of float = +$150,000/year at 4.50%
Rate sensitivity: +100 bps = +$50,000/year on this portfolio
Two Errors in the Usual Float Formula
1 · The stray × 365. Written as "average balance × annual rate × 365," the formula overstates annual interest 365-fold — $82 million instead of $225,000. The displayed answer is right only because the multiplier is quietly dropped when the number is actually computed. An annual rate applied to an average balance already is the annual figure; the day count belongs in the formula only as days / 365 when computing a partial period. Any formula that multiplies by a day count without dividing by one should be checked before it reaches a model.

2 · The float window is not the clearing-to-funding window. Cash float begins when cash is received and ends when it is disbursed. The interval between clearing and merchant funding includes time when the receivable is outstanding but no cash has arrived — and an unsettled receivable is not investable. Measuring float from clearing overstates the investable balance by the settlement lag.

Keep the two intervals separate: receivable financing lag (clearing → cash receipt) drives working capital and the balance-sheet build; cash float (cash receipt → disbursement) drives interest income. Only the second belongs in this calculation. And per Chapter 5, exclude any reserve or other balance that is restricted — restricted cash is not investable either, whatever the aging says.
Dimensional analysis; ASC 835-30-35 for interest recognition where applicable. An FTP credit is an internal allocation, not interest income.
Controller Note — Float is Treasury's Line, Not Operations
Float interest income belongs on the treasury/interest income line, not in operating revenue. Mixing it with MDR revenue inflates the apparent take rate and obscures operating margin. In management reporting, present float income separately. For external financial reporting, float income is typically interest income under ASC 835.

POS Terminal Accounting — Rental vs. Sale

Point-of-sale terminal accounting is one of the most commonly mis-applied areas in acquiring finance. The distinction between a terminal rental (or lease) and a terminal sale is not a billing question — it is a GAAP question with material balance sheet and income statement consequences. Getting this wrong creates overstated or understated assets, misclassified revenue, and potential restatement exposure.

Terminal Sale

When the acquirer sells a terminal to the merchant, title transfers and the merchant owns the hardware. The accounting is straightforward:

Terminal Sale — Journal Entry
At sale date — two entries, revenue and cost recorded separately:

1 · Revenue at the selling price
Dr Cash / AR                           $350
  Cr Revenue — Terminal Sales         $350

2 · Cost of sales and inventory relief
Dr Cost of Sales — Terminals        $180
  Cr Terminal Inventory                 $180

Gross profit: $350 − $180 = $170

Control of the terminal transfers at delivery, so revenue is recognized then.
Revenue Is the Selling Price, Not the Margin
Crediting "Revenue — Terminal Sales $170" and relieving inventory in the same entry books the gross margin as revenue and never records a cost of sales line at all. The entry balances and gross profit is coincidentally right — which is exactly why it survives review — but revenue is understated by $180 and cost of revenue by the same amount.

For a principal sale, revenue is the consideration the entity is entitled to for transferring the terminal: $350. The $180 is a cost of that sale and belongs in cost of revenue. The distortion compounds downstream: hardware revenue disappears from disaggregated revenue disclosure, gross margin percentage is computed off a false base, and any metric using revenue as a denominator — take rate, revenue per merchant — is wrong.

The same test elsewhere: whenever a single entry credits a revenue account for a net amount and relieves an asset in the same breath, check whether a cost of sales line has gone missing. It is the hardware-sale version of the gross-versus-net question in Chapter 3, and the answer comes from the same place — whether the entity controls the good before transfer.
ASC 606-10-32-2; 606-10-55-36 through 55-39A (principal/agent); ASC 330-10-35 (inventory).
Common Error — Terminal "Free with Processing"
Many acquirers offer terminals "free" to merchants who sign multi-year processing agreements. The terminal is not free — but the fix is not to allocate its cost. ASC 606 allocates the transaction price, not costs.

Step 1 — is the terminal a distinct performance obligation? If the merchant obtains control of hardware it can benefit from on its own, yes. If the acquirer retains ownership and the merchant merely uses it, this is not a hardware sale at all — assess PP&E or lease treatment instead (see Terminal Rental below).

Step 2 — if distinct, allocate the transaction price on relative standalone selling prices. The processing contract's total consideration is allocated between the hardware obligation and the processing obligation based on their relative SSPs. Hardware revenue is recognized when control of the terminal transfers — typically at delivery, up front — even though no separate cash was charged for it. The related inventory cost is recognized as cost of sales at the same time. "Free" describes the invoice, not the accounting.

Do not capitalize the terminal cost to defer a loss. Where the hardware obligation has been satisfied, its cost is a cost of that satisfied obligation. Capitalizing it as a fulfillment cost because future processing revenue is expected to recover it inverts the model — ASC 340-40 expressly excludes costs that relate to satisfied performance obligations. A fulfillment-cost asset requires costs that generate or enhance resources used to satisfy obligations in the future, and expected recovery alone does not qualify a cost that has already been earned against.

Where a genuine loss results, because allocated hardware revenue is below terminal cost, recognize it. A contract that is unprofitable on its hardware element and profitable overall is an ordinary commercial outcome, not something to smooth through the balance sheet.
ASC 606-10-25-19 (distinct goods and services); 606-10-32-28 through 32-35 (allocation on relative SSP); ASC 340-40-25-8(c); ASC 330-10.

Terminal Rental / Operating Lease

When the acquirer retains ownership and rents the terminal to the merchant for a monthly fee, the arrangement is likely a lease under ASC 842 — but confirm that first: a lease exists only where the contract conveys the right to control the use of an identified asset for a period in exchange for consideration. Where it does, the acquirer is the lessor, and classification determines the entire treatment.

"No Transfer, No Purchase Option" Does Not Establish an Operating Lease
Those two facts rule out two of the classification criteria. They say nothing about the other three, any one of which independently forces sales-type classification:

Lease term — is it for the major part of the asset's remaining economic life? A three-year rental on a terminal with a three-to-five-year useful life is not obviously outside that.
Present value — do the lease payments plus any residual value guarantee equal or exceed substantially all of the asset's fair value? On a $180 terminal, modest monthly rental over three years frequently does.
Specialized nature — is the asset so specialized it has no alternative use to the lessor at term end?

These are exactly the criteria a terminal rental is most likely to trip, which makes "ownership never transfers" the least informative test to lead with. Run all five and document the conclusion per program, not per portfolio.

Also keep the two sides of the lease straight. As lessor in an operating lease, the acquirer keeps the terminal in PP&E and depreciates it — there is no right-of-use asset on the acquirer's books. The merchant, as lessee, may recognize an ROU asset and lease liability. Describing the acquirer's terminal as an ROU asset confuses the two sides of the same contract.

Short-term relief is an election with its own eligibility. The short-term exemption applies to leases of twelve months or less without a purchase option the lessee is reasonably certain to exercise, and it is a lessee election by class of underlying asset. It is not a general description of terminal rentals, and a three-year rental does not qualify for it under any reading.
ASC 842-10-15-3 (lease identification); 842-10-25-2 through 25-3 (classification criteria); ASC 842-20-25-2 (lessee recognition); ASC 842-30-25 and 35 (lessor).

Operating Lease (most common)

Terminal remains on the acquirer's balance sheet as PP&E. Depreciated over useful life. Monthly rental recognized as revenue over the lease term. No derecognition of the asset. Many terminal rentals land here — but classification requires testing all the criteria, not just checking that ownership does not transfer.

Sales-Type Lease (less common)

Treated as a sale for accounting purposes. Asset derecognized. Net investment in lease recorded. Gross profit recognized at commencement. Interest income recognized over lease term. Triggers when: lease term covers substantially all of the asset's economic life, or PV of lease payments equals substantially all of the asset's fair value. Rare for standard 3-year terminal rental programs.

Operating Lease — Terminal Rental Journal Entries
At terminal deployment:
Dr Terminal Assets (PP&E)            $180 (cost)
  Cr Cash / AP                           $180

Monthly — Depreciation (straight-line, 3-year life):
Dr Depreciation Expense               $5.00/month
  Cr Accumulated Depreciation           $5.00

Monthly — Rental revenue:
Dr Cash / AR                           $15.00/month
  Cr Terminal Rental Revenue           $15.00

Monthly net contribution: $15.00 revenue − $5.00 depreciation = $10.00/terminal/month
TreatmentTerminal SaleOperating Lease (Rental)Sales-Type Lease
Asset on balance sheet?No (derecognized at sale)Yes (PP&E)No (derecognized at commencement)
Revenue recognitionPoint in time at deliveryRatably over lease termUpfront gross profit + interest income
ASC referenceASC 606ASC 842 (lessor)ASC 842 (lessor)
DepreciationN/A post-saleStraight-line over useful lifeN/A post-commencement
Common in practice?Yes — outright sale or bundledYes — most rental programsRare for standard terminal programs
Controller riskBundle analysis under ASC 606Ensure asset register is current; impairment if unreturnedProper classification test documentation
Controller Watch-Out — Terminal Asset Register
The largest terminal accounting risk in an active acquiring portfolio is not the accounting model — it is the asset register. Terminals returned, lost, stolen or simply untracked will sit on the balance sheet indefinitely if the register is not maintained.

Size the exposure at carrying value, not original cost. A portfolio of 50,000 terminals at $180 with 5% annual attrition puts $450,000 of original cost in play each year — but that is not the write-off. These assets have been depreciating since deployment, so the relevant figure is net book value at the date of derecognition. A terminal three years into a five-year life carries roughly 40% of its cost, so the same attrition might represent closer to $180,000 of carrying value. Quoting gross cost as the write-off overstates the exposure and, worse, suggests the register is being reconciled on cost rather than NBV.

A returned terminal is not automatically worthless. Recovered units may be redeployable, refurbishable or saleable. Derecognition applies to assets actually disposed of; assets recovered and returned to inventory transfer at the lower of carrying amount or fair value less costs to sell. Write down what is genuinely unrecoverable — and establish that by reconciling location, ownership, accumulated depreciation and recoverability, not by assuming attrition equals loss.

Control: reconcile the register against active MIDs at least annually, tracking four attributes per unit — physical location, ownership (sold, leased, acquirer-owned), accumulated depreciation, and recovery status. Terminals at terminated merchants with no return confirmation should be assessed for impairment on a defined timetable rather than left to age.
ASC 360-10-35-21 (impairment indicators) and 35-29; ASC 330-10 for recovered units returned to inventory.
Controller Watch-Out — Bundled Terminal + Processing
When terminal rental is bundled with the processing agreement into a single monthly fee (very common in ISO and direct sales models — e.g., "$29.99/month all-in"), the contract contains both a lease component and a non-lease service component. The default is to separate them and allocate the consideration on relative standalone selling prices, with the rental accounted for under ASC 842 and the processing under ASC 606. Failing to allocate misstates both lines.

But separation is not the only permitted answer. A lessor may elect, by class of underlying asset, to combine qualifying non-lease components with the associated lease component where the timing and pattern of transfer are the same and the lease would be classified as an operating lease. Where that election is available and made, the combined component is accounted for under whichever guidance predominates. Asserting that allocation is mandatory in every case overstates the requirement — establish eligibility, make the election deliberately, and document it. What is not defensible is leaving the components merged without having considered either path.
ASC 842-10-15-38 through 15-42B (separating and combining lease and non-lease components; lessor practical expedient); ASC 606-10-32-28 through 32-35.

Controller Checklist — KPIs & POS Accounting

Monthly KPI Close Controls
□ Net take rate calculated and documented: (MDR − IC − Scheme) / GTV × 10,000 = bps
□ Gross take rate tracked separately: MDR / GTV × 10,000 (never confuse with net)
□ IC cost % of GTV calculated from network settlement file — not estimated
□ CB rate by merchant updated weekly against your documented internal alert threshold and the current Visa VAMP / Mastercard ECP parameters
□ Auth-to-clear conversion rate calculated for prior week by MCC
□ Downgrade rate: EIRF + Standard volume / total volume — target below 2%
□ Float income calculated and classified as interest income (not operating revenue)
□ Terminal asset register reconciled to active MID count — terminated merchant terminals flagged
□ POS terminal depreciation schedule current — no fully depreciated assets still on books without physical confirmation
□ Any bundled terminal + processing arrangement reviewed for ASC 606/842 allocation
🔍 Controller Lens — KPIs & POS Accounting
WHAT CREATES THE ASSET?POS terminal purchase creates a fixed asset (at cost). Terminal rental to merchant creates a right-of-use asset only if the arrangement qualifies as a lease under ASC 842. Most terminal rentals are short-term operating leases — recognize rental income ratably, no right-of-use asset.
SOURCE OF TRUTHTerminal asset register tied to active MID count. Any terminal at a terminated merchant with no return confirmation is either a receivable (if returnable) or should be written down (if unrecoverable). The register must be a living document, not an annual exercise.
TIMINGFloat income recognized monthly as interest. Terminal depreciation runs on schedule regardless of utilization. Bundled terminal + processing fees must be allocated between ASC 842 (rental) and ASC 606 (processing) at contract inception — not retrospectively.
KEY RISKGhost terminals — physically returned or lost but still on books at net book value. Float income classified as operating revenue instead of interest income (inflates take rate). Bundled arrangement with no SSP allocation (audit finding in Year 1 of any Big 4 audit).
Chapter 11

Issuing Side
Accounting

The same transaction, opposite accounting. How interchange, network fees, rewards, interest income, charge-offs, and co-brand economics work from the issuer's perspective — and why every acquirer controller needs to understand both sides.

Every card transaction has two sides of the ledger. The acquiring side earns MDR and pays interchange as a cost. The issuing side receives that interchange as revenue and pays network fees, funds rewards, and bears credit risk. Understanding both sides is directly useful — it affects how you read interchange economics, evaluate partner agreements, interpret co-brand deal terms, and explain pricing decisions to leadership.

The Core Asymmetry
On a $100 transaction at 1.65% interchange: the acquirer pays $1.65 to the issuer (it's a cost). The issuer receives $1.65 (it's revenue). Same dollar, opposite P&L treatment. Same network fees, different direction. Understanding this asymmetry is foundational to cross-side economics.

Interchange as Issuer Revenue

For the issuer, interchange is the primary revenue driver on card transactions. Under ASC 606, interchange is recognized at the point each transaction clears — it meets the performance obligation (providing the credit/debit authorization service) at that moment. Unlike acquiring MDR, the issuer does not have a direct relationship with the merchant; interchange flows through the network as a fee set by the network and collected by the issuer per cleared transaction.

Issuer Interchange Revenue — $100M Acquiring Portfolio (Mirror)
If acquiring portfolio GTV = $100M at blended 1.65% interchange:
Issuer portfolio receives: $100M × 1.65% = $1,650,000 interchange income
Less: Network assessment fees paid by issuer ≈ 0.11% = $110,000
Less: Rewards expense (cash back, points) ≈ 0.80% = $800,000
Less: Processing/infrastructure cost ≈ 0.15% = $150,000
Net interchange margin ≈ $590,000 (59 bps on GTV)

Issuer P&L Structure

Revenue/Cost LineDriverASC ReferenceController Note
Interchange IncomeGTV × interchange rateASC 606 — recognized at clearingPrimary revenue driver; rate varies by card type and merchant MCC
Interest IncomeAverage revolving balance × APR / 365ASC 310 / ASC 835Largest P&L line for credit card issuers; accrued daily
Annual FeesCardholders paying annual card feesASC 310-20 — not ASC 606Credit-card lending arrangements are outside ASC 606 scope. Periodic annual fees are generally deferred and recognized over the period they cover
Late / Penalty FeesMissed minimum paymentsASC 310-20 — not ASC 606A fee within the lending arrangement, not consideration for a promised service. Subject to CARD Act limits
Network Assessment FeesGTV × issuer assessment ratePeriod costPaid to Visa/MC on volume; separate from acquirer assessments
Rewards ExpensePoints/cash-back earned on spendDepends on the program — not ASC 420Most contested judgment in card issuing. Scope, counterparty and obligation drive the model — see below
Charge-offsUncollectible receivables written offASC 326 (CECL)Day-1 CECL reserve required; charge-off reduces reserve, not P&L
Co-brand Revenue SharePer agreement with brand partnerASC 606Often structured as revenue share on interchange + GTV bonuses
Not Every Issuer Fee Lives in ASC 606
Issuers earn from two structurally different arrangements, and assigning every fee to ASC 606 misses the scope boundary:

The lending arrangement — the credit extended to the cardholder. Fees within it (annual fees, late fees, over-limit fees, cash advance fees) are outside ASC 606's scope, which expressly excludes financial instruments and related contractual rights. They follow ASC 310-20, under which periodic annual fees are generally deferred and recognized over the period the fee covers.
Service arrangements — interchange for processing services, co-brand partner arrangements, and similar promises to a customer. These are assessed under ASC 606 in the normal way.

The practical outcome for an annual fee often looks similar under either label — deferral across twelve months — which is why the misattribution survives. But it breaks down elsewhere. Late fees are not consideration for a promised service and have no ASC 606 performance obligation to attach to; forcing them into ASC 606 produces a revenue memo that cannot describe what was promised. Debit programs, prepaid and non-lending service fees need their own analysis rather than inheriting the credit conclusion.

Control: classify each issuer revenue line by arrangement first — lending or service — then apply the standard that governs it. Doing it fee-by-fee without that step is how a single rule ends up applied to everything.
ASC 606-10-15-2(c) (scope exclusion); ASC 310-20-25-15.

Rewards Expense — The Most Contested Accounting

Rewards are the single most judgment-intensive accounting item in card issuing — and the first thing to establish is which model even applies.

ASC 420 Is Not a Rewards Standard
ASC 420 addresses exit and disposal cost obligations — restructuring, terminating contracts, consolidating facilities. It has nothing to do with card rewards, and citing it signals the scope question was never asked. Delete it from the analysis.

The cash-back-versus-points distinction does not determine the model either. Whether a reward is denominated in dollars or points is a program design feature; it does not establish the accounting. Three questions do:

1 · What arrangement does the reward sit in? A reward earned as part of the lending relationship with the cardholder is typically accounted for under an estimated-cost liability model, outside ASC 606 for the same scope reason as the fees above.
2 · Who is the counterparty and what was promised? Where a program creates a separate obligation to provide future goods or services to a customer, that is a material right requiring its own ASC 606 analysis — allocation of transaction price to the option, recognition when the option is exercised or expires.
3 · Is it expense or deferred revenue? These are different things and are frequently conflated. An estimated liability for the cost of rewards the issuer expects to deliver is an expense accrual. A material right under ASC 606 defers revenue until the right is exercised or lapses. They hit different lines and behave differently as the program matures.

On breakage: where ASC 606 applies, breakage is recognized in proportion to the pattern of rights actually exercised — not simply as points are earned, and not by writing off unredeemed points on a schedule. Where an estimated-cost liability model applies instead, expected non-redemption is a measurement input to that liability. Same word, different mechanics; be explicit about which one the model is using.
ASC 420-10-15 (scope — exit and disposal costs); ASC 606-10-15-2(c); ASC 606-10-55-42 through 55-49 (customer options and breakage); ASC 450-20-25-2.

With the scope settled, the presentation question below — reduction of revenue versus operating expense — turns on whether the reward is intrinsically tied to the consideration earned or represents a separate obligation.

Contra-Revenue Treatment

If rewards are intrinsically tied to the interchange earned on each transaction (e.g., "earn 1.5% cash back on every purchase"), the rewards expense is a reduction of the interchange revenue. Net interchange = gross interchange − rewards earned. Common for simple cash-back cards with no separate loyalty program.

Operating Expense Treatment

If rewards are part of a multi-element loyalty program (points that can be redeemed across products, tiered benefits, transfer partners), they may be accounted for as a separate performance obligation or a liability (deferred revenue) until redemption. More common for premium travel cards with complex reward structures.

Breakage Estimate

Not all rewards are redeemed. The issuer must estimate breakage — the portion of earned rewards expected to expire unredeemed — and recognize that portion proportionally as rewards are earned. Breakage estimates require significant historical data and are a key audit focus area.

CECL Impact on Charge-offs

Under ASC 326, issuers must estimate lifetime expected credit losses on day 1. The CECL reserve is established at origination, not when a loss becomes probable. Charge-offs reduce the reserve (not the income statement). The P&L impact is the day-1 provision, not the eventual write-off.

Co-brand Economics — Controller Framework

Co-brand agreements (e.g., airline cards, retail cards) create complex revenue sharing arrangements between the card issuer and the brand partner. The dominant co-brand structure today is the issuer paying the brand partner a royalty — typically a per-account fee, a per-spend fee, or a revenue share on net portfolio economics — in exchange for the brand providing its customer base and exclusive card rights. Some legacy structures pass a portion of interchange directly to the brand, but modern co-brand deals are more commonly structured as royalty payments tied to GTV or portfolio profitability, not interchange splits. For the issuer's controller, co-brand payments are typically a cost of revenue — either a contra-revenue against interchange or a customer acquisition/retention cost depending on the specific contractual structure.

Co-brand P&L — Illustrative Structure
Issuer interchange income: $1,650,000 (1.65% on $100M GTV)
Less: Co-brand partner revenue share (35% of interchange): ($577,500)
Less: Rewards expense funded by issuer (0.50% on GTV): ($500,000)
Less: Network fees: ($110,000)
Net co-brand contribution: $462,500 (46 bps)

Note: Partner revenue share classification (contra-revenue vs. cost) requires
ASC 606 analysis of whether partner provides a distinct service to the issuer.
Controller Watch-Out — Same Transaction, Different Books
If your organization has both acquiring and issuing operations, the same transaction will appear in two P&Ls. The acquiring side pays interchange as expense; the issuing side receives it as revenue. In consolidated financials, intra-company transactions eliminate. But in segment reporting, the failure to understand which side owns which P&L lines creates misattribution of margin — a common source of management reporting errors in diversified financial institutions.

CECL & Allowance for Credit Losses — Deep Dive (ASC 326)

CECL (Current Expected Credit Loss) replaced the incurred loss model in 2020 for large public companies and represents the most significant change to credit accounting in decades. For issuers, CECL requires estimating the lifetime expected credit loss on every financial asset at the moment of origination — not when a loss becomes probable. The P&L impact of extending credit is front-loaded under CECL; the income statement sees the provision on Day 1.

The Pre-CECL vs. CECL Contrast
Old model (ASC 450 incurred loss): Recognize a loss reserve only when a loss is probable and estimable. Reserve builds slowly as delinquency emerges. P&L hit is spread across the delinquency and charge-off timeline.

CECL (ASC 326): On day 1 of recognizing a financial asset, estimate the full lifetime expected loss and book the provision immediately — before a single payment is missed.
A Credit Limit Is Not a Loan — Two Scope Errors to Avoid
1 · Undrawn limits are not funded assets. An issuer that approves $1B of new credit limits in January has not originated $1B of receivables. CECL applies to the drawn balance — the financial asset actually recognized. If cardholders draw $120M against that $1B of availability, the allowance is measured on the $120M. Provisioning the full limit overstates the allowance by roughly an order of magnitude and makes the model impossible to reconcile to the balance sheet.

2 · Unconditionally cancellable commitments carry no CECL liability. Expected credit losses on off-balance-sheet credit exposures are recognized only where the entity is obligated to extend credit. Credit-card availability that the issuer can cancel unconditionally is excluded — no liability is recorded for the undrawn portion. This is a specific and well-settled point in the card context, and it is the reason a card portfolio's allowance tracks balances rather than limits. Where a commitment is not unconditionally cancellable, a liability is required, so the cancellability terms are worth confirming rather than assuming.

And CECL does not cover every financial asset. ASC 326-20 applies to financial assets measured at amortized cost; assets measured at fair value through net income, among others, are outside it. Saying "CECL covers everything" invites applying the model where it does not belong and skipping the scope test where it does.

Control: reconcile the CECL exposure base to the balance sheet each period. If the base does not tie to recognized receivables plus any non-cancellable commitments, the model is measuring something the financial statements do not contain.
ASC 326-20-15-2 through 15-3 (scope); 326-20-30-11 (off-balance-sheet credit exposures); 326-20-55-54 through 55-56.

CECL Calculation Methodology

ASC 326 does not prescribe a specific method — it requires the estimate to reflect reasonable and supportable forecasts of future economic conditions. In practice, card issuers use one of three approaches, often in combination:

Probability of Default / Loss Given Default (PD/LGD)

The most granular approach. Models the probability that a specific account defaults (PD) and the loss rate if it does (LGD). Applied to each account's outstanding balance. Requires robust credit scoring data and economic scenario models. Used by large bank card issuers.

Vintage Analysis

Groups accounts by origination vintage (month/quarter) and tracks cumulative loss rates over time for each cohort. Applies historical loss curves to the current portfolio composition, adjusted for current economic conditions. Common for issuers with large homogeneous portfolios.

Roll-Rate Method

Tracks the probability of accounts "rolling" from one delinquency bucket to the next (Current → 30 DPD → 60 DPD → 90 DPD → Charge-off). Multiply roll rates by outstanding balances at each bucket to estimate lifetime loss. Intuitive and transparent — auditors and regulators respond well to it.

DCF / Cash Flow Method

For loans with contractual cash flows, project expected future payments, discount at the effective interest rate, and recognize the difference between expected and contractual cash flows as the allowance. More common for mortgage and auto loans than revolving credit cards.

Allowance for Credit Losses — Journal Entry Lifecycle

CECL Entries — Card Issuer, $100M New Originations, 5% Lifetime Loss Rate
Day 1 — Origination and CECL provision:
Dr Card Receivable                $100,000,000  (new credit extended)
  Cr Cash / Funding Obligation      $100,000,000

Dr Credit Loss Expense (P&L)       $5,000,000  (5% lifetime loss estimate)
  Cr Allowance for Credit Losses    $5,000,000  (contra-asset on balance sheet)

Monthly — Accrual of interest income on performing balances:
Dr Card Receivable                $1,833,333
  Cr Interest Income                  $1,833,333  ($100M × 22% APR / 12)

When account charges off (balance uncollectible after 180 DPD):
Dr Allowance for Credit Losses    $3,200,000  (actual charge-off)
  Cr Card Receivable                $3,200,000
Note: Charge-off REDUCES the allowance. It does NOT hit the income statement.
The P&L was charged when the provision was booked, not at charge-off.

Subsequent recoveries (cardholder pays after charge-off):
Dr Cash                            $400,000
  Cr Allowance for Credit Losses    $400,000  (recovery increases allowance)

Key CECL Ratios — Controller Monitoring

MetricFormulaBenchmarkController Alert
Coverage RatioAllowance for Credit Losses / Total Receivables3–8% for credit cards (varies by portfolio quality)Ratio declining QoQ while delinquency stable → model may be inadequate
Net Charge-off Rate (NCO)Annualized Net Charge-offs / Average Receivables2–4% for prime; 8–15% for subprimeNCO > provision rate → allowance being depleted; reprovision required
Provision-to-NCO RatioCredit Loss Provision / Net Charge-offs>1.0x (building reserve) during growth; ~1.0x steady state<0.8x for 2+ quarters = reserve depletion; CECL model review required
30/60/90 DPD RateDelinquent Balances / Total Receivables by bucketLeading indicator: 30 DPD <2% healthy prime30 DPD rising is current information — reflect it in this reporting date's estimate, not a future one
Allowance AdequacyAllowance / Forward 12-Month Expected Losses>1.0x (fully reserved for near-term losses)<0.9x requires immediate escalation to CAO/credit risk
Controller Watch-Out — Qualitative Adjustment Governance
CECL models produce a quantitative estimate, but management is permitted to apply qualitative adjustments (Q-factors) to reflect conditions not captured by historical data — new geographies, economic regime changes, model uncertainty. These Q-factors are a major audit focus area. The controller must: (1) document the rationale for every Q-factor, (2) ensure Q-factors are directionally consistent with observable risk indicators, (3) get CAO and credit risk approval before booking any Q-factor adjustment, (4) maintain a Q-factor log with period-over-period changes. A Q-factor with no documented rationale = material weakness candidate.
Ratios Monitor the Estimate — They Do Not Set It
Threshold rules such as "reprovision if provision-to-NCO falls below 0.8x for two quarters" or "escalate if coverage drops below 0.9x" are useful internal monitoring tools. They are not the measurement model, and must never override it.

The estimate is made afresh at each reporting date. CECL requires a current lifetime expected-loss estimate reflecting information available now, including reasonable and supportable forecasts. If 30-day delinquency is rising today, that is current information and belongs in today's estimate. Guidance that the provision "will need to increase in 60–90 days" is a lagged, incurred-loss reflex — precisely the behavior CECL was written to eliminate. Waiting for a ratio to breach, or for delinquency to mature into charge-offs, defers a provision that is already required.

A mechanical ratio can point the wrong way. A shrinking portfolio with improving credit quality can show a falling provision-to-NCO ratio while being correctly reserved; a growing portfolio can show a comfortable ratio while under-reserved against a deteriorating forecast. Use ratios to prompt inquiry, and let the inquiry — not the ratio — determine the number.

Label internal requirements as internal. Independent annual model validation is common and often sound, and may well be required by your regulator or your own model-risk policy. But it is not established by the accounting standard, and calling it a blanket SOX requirement for public companies misstates its source. Cite the actual authority so a reader can tell what is mandatory for them and what is recommended practice.
ASC 326-20-30-2 through 30-9 (measurement); ASC 326-20-35-1 (each reporting date). The ASC does not establish an annual independent-validation requirement.
Controller Checklist — CECL & Allowance
□ CECL model inputs (PD, LGD, EAD) updated with current portfolio data monthly
□ Economic scenario weightings reviewed quarterly by credit risk and finance
□ Qualitative adjustments documented with rationale and senior approval
□ Charge-offs reducing allowance, not P&L — entry verified monthly
□ Recovery postings increasing allowance confirmed
□ Coverage ratio trend tracked and explained to management
□ Provision-to-NCO and coverage ratios monitored against documented internal escalation settings — these prompt review, they do not determine the estimate
□ Back-testing: compare prior CECL estimates to actual losses — document gaps
□ Model validation performed on the cadence your own model-risk policy and applicable regulatory expectations require
🔍 Controller Lens — Issuing Side Accounting
WHAT CREATES THE ASSET?Cardholder receivable created when credit extended. Accrued interest increases it daily. CECL allowance (contra-asset) reduces net carrying value from Day 1.
SOURCE OF TRUTHCard management system for balances and rates. Network settlement file for interchange income. Co-brand agreement for rev share calculation. All three sources required for issuer P&L close.
TIMINGInterchange income = clearing date. Interest income = daily accrual. CECL provision = Day 1 of origination. Charge-offs reduce allowance (not P&L). Rewards recognized when earned (or at redemption depending on model).
KEY RISKRewards misclassified (contra-revenue vs. expense). CECL Q-factors undocumented. Co-brand rev share in wrong classification. Same-transaction interchange income vs. expense confusion in consolidated entity.
Chapter 12

Revenue Share &
Partner Economics

ISO residuals, PayFac splits, issuer revenue share, and co-brand deal mechanics — the calculation logic, contract interpretation, system gaps, and audit risks that controllers must own.

Revenue share arrangements are among the most complex accounting and operational challenges in payments finance. The economics flow in multiple directions — acquirers pay ISOs, PayFacs pay sub-merchants, issuers pay co-brand partners, networks pay volume incentives — and each flow has its own recognition timing, classification treatment, and reconciliation requirement. If your revenue share liability is unreconciled, your P&L is wrong.

ISO Residuals

An ISO (Independent Sales Organization) earns a residual — a share of the net revenue generated by the merchants it introduced to the acquirer. Residuals are typically calculated as a percentage of the acquirer's net margin (MDR minus interchange minus scheme fees) on the ISO's portfolio, paid monthly in arrears.

ISO Residual Calculation — Standard Model
Scenario B rates (2.30% / 1.65% / 0.14%), applied to the ISO's portfolio.

ISO Portfolio GTV: $10,000,000/month
Blended MDR 2.30% → MDR Revenue: $230,000
Interchange cost (1.65%): $165,000
Scheme fees (0.14%): $14,000
Acquirer net margin: $230,000 − $165,000 − $14,000 = $51,000 (51 bps)
ISO residual split (50%): $25,500/month

Controller note: the residual base and split % are defined in the ISO agreement.
Some agreements pay on gross MDR before cost deduction — read the contract.
Check the Rate Against the Dollars
Stating MDR revenue as $175,000 while quoting a 2.30% rate on $10M is internally impossible — 2.30% of $10,000,000 is $230,000. The error is easy to miss because the rest of the schedule is right and the margin still reads $51,000: $175,000 less $165,000 of interchange and $14,000 of scheme fees would actually be negative $4,000, so a positive $51,000 can only have come from the correct $230,000. One line was overwritten and the total was never recomputed.

The consequence is not cosmetic. The residual is calculated off net margin, so an understated revenue line understates the ISO's entitlement. On this portfolio the difference is $27,500 a month of margin, which at a 50% split is roughly $165,000 a year of residual per ISO — and residual disputes are settled against the contract, not against your schedule.

Control: in any rate-and-dollar schedule, recompute at least one line from the stated rate before relying on it, and confirm the margin ties to revenue minus costs rather than to a separately remembered figure. Where a later example uses different economics — a 22-bp portfolio rather than this 51-bp one — label it as a distinct scenario instead of letting two rate sets share a section.
ASC 606-10-32-2.
ASC 340-40 — Residual Capitalization Test
ISO signing bonuses and upfront payments paid to bring an ISO onto the platform are incremental costs of obtaining a contract. If they are expected to be recovered from future residual payments, they must be capitalized under ASC 340-40 and amortized over the expected ISO relationship life. Expensing them immediately is an ASC 340-40 violation unless the amortization period would be one year or less (practical expedient).

PayFac Sub-Merchant Splits

A Payment Facilitator (PayFac) operates under a master MID and boards sub-merchants under its umbrella. The PayFac charges sub-merchants a blended rate (typically 2.5–3.5% for SMB), pays the acquirer a wholesale rate (interchange + acquirer markup), and retains the spread. This creates a layered P&L that the PayFac controller must model explicitly.

PayFac Economics — Sub-Merchant Split
Sub-merchant GTV: $1,000,000
PayFac charges sub-merchant: 2.90% = $29,000 (PayFac revenue)
PayFac pays acquirer: interchange 1.65% + acquirer markup 0.25% = 1.90% = $19,000
PayFac gross margin: $29,000 − $19,000 = $10,000 (100 bps)
Less: PayFac infrastructure / risk cost: ~$3,000
PayFac net margin: $7,000 (70 bps)

Chargeback exposure: the PayFac typically carries responsibility to its sponsor
and the network for sub-merchant activity, with recourse downstream — read the
agreements before assuming either extreme. Reserve against the sub-merchant
portfolio, not just individual exposure.
"Bears ALL the Risk" Is a Contract Question, Not a Given
Risk allocation in a PayFac structure is set by a stack of agreements, and the answer differs by program:

Responsibility to the network runs through the sponsoring acquirer, which remains the network's member and is answerable for its PayFac's sub-merchants under the network rules.
Responsibility between sponsor and PayFac is set by the sponsorship agreement — including indemnities, reserve requirements and loss-sharing.
Recourse to the sub-merchant is set by the platform's own terms, and is only as good as the sub-merchant's ability to pay.

Being responsible to the network is not the same as bearing the ultimate loss, and neither is the same as having no recourse. Map the three layers for your own program before sizing reserves — a PayFac with strong sub-merchant recourse and a sponsor-funded loss pool has a materially different exposure from one holding the full first-loss position.

Two things not to carry over from this analysis. First, risk allocation does not determine the principal/agent conclusion — credit and loss exposure were removed as indicators (Chapter 3), so bearing chargeback risk is not evidence of principal status however commercially significant it is. Second, treat any "fintech restated after IPO" anecdote as illustrative unless you can point to the specific filing. Unattributed restatement stories circulate widely in this corner of the industry, mutate in the retelling, and do not belong in a technical memo as support.
ASC 606-10-55-36 through 55-39A. Member responsibility for sponsored entities: Visa Core Rules §§1.5.1 and 5.3; Mastercard Security Rules and Procedures §6.2.2.

Revenue Share Classification — Contra vs. Expense

The most frequent audit finding in payments revenue share accounting is misclassification between contra-revenue and operating expense. The distinction matters materially for gross revenue presentation under ASC 606.

Payment TypeCorrect ClassificationRationaleAudit Risk
ISO residual on net marginOperating expense (cost of revenue)ISO provides a distinct selling service; payment is for that serviceMisclassifying as contra-revenue understates gross revenue
Co-brand partner % of interchangeContra-revenue OR cost of revenueDepends on whether partner provides a distinct service to the acquirer/issuerClassification affects gross vs. net revenue presentation
Volume incentives to merchantsContra-revenue (variable consideration)Reduces the transaction price per ASC 606-10-32-25; not a separate serviceMisclassifying as marketing expense overstates revenue
PayFac sub-merchant fundingNot revenue — settlement liabilityPayFac is a principal; sub-merchant payment is settlement, not a revenue shareNetting sub-merchant payments against revenue = misstatement
Network volume incentives (rebates)Contra-expense (reduces scheme fee cost)Network pays incentive on volume; reduces net scheme fee costRecording as other income instead of expense reduction distorts margins
A Signing Bonus Is Not Capitalizable Just Because It Will Be "Recovered"
The common justification — "$100,000 bonus against $396,000 of expected residual payments over 36 months, therefore recoverable" — inverts the test. Those residual payments are money the acquirer pays out to the ISO. They are costs of the arrangement, not inflows. Citing a larger future outflow as proof that an upfront outflow is recoverable is not a recoverability analysis; it is two costs compared to each other.

Test recovery against expected net benefits. The relevant comparison is the carrying amount against the consideration the acquirer expects to receive from the portfolio the ISO brings, less the costs directly related to earning it — including the residuals payable to that ISO. If the portfolio generates $51,000 a month of acquirer margin and $25,500 goes back to the ISO, the benefit available to support the asset is the remainder, not the gross.

Establish it is an incremental cost of obtaining a contract with a customer. Two questions come first. Who is the customer? An ISO that introduces merchants may be a channel partner rather than the customer, and the customer contracts may be the merchant agreements — which changes what the cost attaches to. Is the payment incremental? A bonus payable only on signing generally is; a payment the acquirer would make regardless is not. And where the recipient is itself a customer, the payment may instead be consideration payable to a customer that reduces the transaction price rather than creating an asset.

Recurring residuals need their own analysis too. They are not automatically immediate expense. Where a residual is genuinely a cost of obtaining a contract and meets the criteria, it may qualify for capitalization; where it is consideration for an ongoing distinct service, it is expensed as that service is received. Determine the amortization period from the services the cost actually benefits, including anticipated renewals where applicable — not from the term of the ISO agreement by default.
ASC 340-40-25-1 through 25-8; 340-40-35-1 through 35-4 (amortization and impairment); ASC 606-10-32-25 through 32-27 where the recipient is also a customer.

Network Volume Incentives — Received by Acquirer

Large acquirers often receive volume incentive payments from Visa and Mastercard in exchange for routing volume commitments or achieving volume targets. These are sometimes called "network incentives" or "volume rebates" and are negotiated annually. They are typically structured as: a fixed annual amount payable quarterly, and/or a variable component tied to volume growth above a threshold.

Controller Watch-Out — Incentive Accrual Complexity
Network incentives are often paid in arrears on a quarterly or annual basis with complex volume-tier calculations. The controller must: (1) estimate the full-year incentive based on current volume trajectory, (2) accrue monthly based on that estimate, (3) true-up when actual payments are received. If volume falls short of commitment tiers mid-year, the accrual must be reversed. This creates P&L volatility that must be disclosed and documented with a formal estimation methodology.
Network Incentive Monthly Accrual
Annual network incentive contract: $12,000,000 (based on $1.2B annual GTV commitment)
Monthly accrual if the arrangement is earned evenly: $12,000,000 / 12 = $1,000,000/month
Quarterly cash receipt: $3,000,000
True-up at Q-end: Actual quarterly accrual vs. cash received → book difference

If GTV tracks below commitment at M+8: reduce accrual rate; reverse excess
Classification: generally reduces the related purchase cost — see the note below
Three Assumptions Buried in a Straight-Line Incentive Accrual
1 · That it is earned evenly. Straight-lining is appropriate only where the arrangement is actually earned that way. Most network incentives are tied to volume, tiers or growth thresholds — none of which accrue in equal monthly instalments when volume is seasonal. Accrue on the basis the incentive is actually earned on, and where achievement is uncertain, recognize only the amount not at significant risk of reversal rather than booking a full monthly twelfth and reversing later.

2 · That it is unconditionally receivable. Debiting a receivable each month asserts an unconditional right to consideration. Where the incentive depends on meeting a full-year commitment, that right is conditional until the condition is satisfied — the balance is a contract-asset-like position subject to reversal, not a receivable. Recording it as a receivable overstates the asset's quality and hides the clawback exposure.

3 · That it always nets against scheme fees. Consideration received from a vendor is generally presumed to reduce the cost of purchases from that vendor. But if the acquirer provides a distinct service to the network in exchange — and it is identifiable and fair-value measurable — that portion may instead be revenue or a reimbursement of costs. Establish which applies rather than defaulting to contra-expense.

And sanity-check the magnitude. A $12M incentive against $1.2B of volume is 100 bps. At the 0.14% scheme rate used elsewhere in this handbook, that volume attracts roughly $1.68M of annual scheme fees — so a $12M incentive is about seven times the entire fee base it supposedly reduces. Netting it against scheme fees would drive that line deeply negative, which is a strong signal the incentive is compensating something else entirely (routing commitments, brand agreements, multi-year exclusivity) or that the figures come from unrelated scenarios. Whenever an incentive exceeds the cost base it offsets, explain the economic base explicitly — it will be the first thing a reviewer asks about.
ASC 705-20-25-1 through 25-6 (consideration from a vendor); ASC 606-10-15-3 where a distinct service is provided to the network.

System Gaps — The Controller's Operational Risk

Audit Evidence — Revenue Share Reconciliation
The most common system gap in revenue share accounting: the ISO/partner payment system does not tie to the transaction processing system. ISO residuals are calculated by one system; transaction data lives in another. The controller must build a reconciliation bridge — ideally automated — that ties residual payments to the underlying transaction detail. Without this, residuals can be over- or under-paid with no audit trail. SOX requires this reconciliation to be a documented, tested control.
🔍 Controller Lens — Revenue Share & Partner Economics
WHAT CREATES THE LIABILITY?ISO residuals accrue as a % of net margin earned on the ISO's merchant portfolio, calculated monthly. Liability created when earned, paid in arrears. Network incentives create a receivable when volume thresholds are hit.
SOURCE OF TRUTHISO agreement (residual %, basis, payment terms). Processing system (merchant GTV by ISO). Network incentive contract (volume tiers). System gap: these often don't talk to each other — build the bridge manually.
TIMINGResiduals: earned in period, paid month+1. Network incentives: earned ratably, received quarterly. Volume incentive true-up: annual. Each has different accrual and true-up timing.
KEY RISKISO residual overpaid (system doesn't net reversals). Volume incentive overaccrued (GTV tracking below commitment). Co-brand payment misclassified. No sub-ledger tying GL to partner-level detail.

ISO Agreement — Key Controller Checkpoints

Contract TermAccounting ImpactWhat to Verify
Residual basis (gross MDR vs. net margin)Determines whether residual is 50% of $1.75M or 50% of $220K — 8x differenceRead the exact definition in the ISO agreement — not the summary
Clawback provisionsReversal risk on residuals already paid if merchant churns within 6–12 monthsAccrual reserve needed for estimated clawbacks based on historical churn rates
Minimum volume commitmentsIf ISO doesn't hit minimums, acquirer may owe penalties or reduced residualsTrack ISO portfolio GTV monthly against contract minimums
Residual payment timingPaid in arrears — create accrued liability in processing month, clear on payment dateConfirm accrual date matches earned period, not payment date
Revenue share capSome agreements cap total residual regardless of volume growthModel the cap scenario; flag when portfolio approaches cap threshold

Controller Checklist — Revenue Share

Revenue Share Close Controls
□ ISO residual calculated from correct basis (gross MDR vs. net margin per contract)
□ Residual calculation reconciled to transaction detail by ISO ID
□ ASC 340-40 capitalization test run for any ISO signing bonus or upfront payment
□ Network incentive accrual updated based on current-year GTV trajectory vs. commitment
□ Co-brand partner payment classified correctly (contra-revenue vs. cost of revenue)
□ Volume incentive true-up estimated if year-end within 90 days
□ Clawback reserve assessed against recent ISO churn history
□ Revenue share liability tied to individual ISO sub-ledger (not just GL total)

Journal Entries — Revenue Share Accounting

ISO Residual — Monthly Accrual and Payment
This entry uses Scenario A (22 bps), not the 51-bp Scenario B portfolio
in the calculation above — a deliberately different ISO book. On $10M at 22 bps
the net margin is $22,000 and the 50% residual is $11,000.


Month-end accrual (ISO earns residual in processing month):
Dr ISO Residual Expense                $11,000    (50% of $22,000 net margin)
  Cr ISO Residual Payable                 $11,000

Following month payment:
Dr ISO Residual Payable                $11,000
  Cr Cash                                    $11,000

Classification note: ISO residual = operating expense (cost of revenue).
ISO provides a distinct selling service — it is NOT contra-revenue.
Misclassifying as contra-revenue understates gross MDR revenue.

ASC 340-40 — ISO Signing Bonus (capitalization is not automatic):
Acquirer pays a $100,000 signing bonus to onboard a new ISO with a $5M/month portfolio.
Recoverability must be tested against expected net benefits — see the note below.
The residual payments the acquirer owes the ISO are costs, not evidence of recovery.

Dr Contract Acquisition Cost (Asset)   $100,000
  Cr Cash                                    $100,000

Monthly amortization over 36 months:
Dr Amortization Expense                  $2,778
  Cr Contract Acquisition Cost              $2,778

Network Volume Incentive — Monthly Accrual (separate contract scenario;
see the sizing note below — the economics do not derive from the portfolios above):

Annual incentive contract $12M on $1.2B volume commitment:
Dr Network Incentive Receivable         $1,000,000
  Cr Scheme Fee Expense (contra)          $1,000,000  (reduces scheme fee cost — not revenue)

Quarterly cash receipt:
Dr Cash                                    $3,000,000
  Cr Network Incentive Receivable         $3,000,000

PayFac as a Service (PFaaS) — Controller Framework

The payments distribution model has evolved through four distinct stages, each with different accounting implications for platforms. Understanding where your platform sits in this evolution determines how you recognize revenue, classify merchant payments, and assess ASC 606 principal vs. agent status.

Evolution of Payment Distribution — Controller Accounting Implications
STAGE 1 Traditional Processing Merchant applies for own MID. Direct acquirer relationship. Accounting: simple acquirer model STAGE 2 PayFac Master MID. Sub-merchants onboarded under platform umbrella. Accounting: platform bears all CB risk STAGE 3 PFaaS Platform uses third-party PayFac infrastructure. Stripe Connect, Adyen for Platforms. Accounting: agent? EMERGING Embedded Finance Platform is the financial product. Shopify Balance, Toast Capital. Accounting: complex principal + lending

PFaaS — The ASC 606 Principal vs. Agent Question

When a platform uses PFaaS (e.g. Stripe Connect, Adyen for Platforms), the revenue recognition question is whether the platform is a principal or an agent for the payment processing service — and therefore whether it reports the gross processing consideration or only its net fee.

Gross Does Not Mean the Merchant's Sales
The framing "$1M of payment volume or $30K of fees" presents a false choice, and the $1M end of it is wrong under either conclusion. Payment volume is not the platform's revenue. It is the merchants' sales, collected on their behalf and owed straight back to them.

Two separate analyses are being merged:

Processing service. Did the platform control the payment processing service provided to its merchants? If yes, it is a principal for that service and reports the gross consideration it charges for it — the $30K of fees, presented gross against the processing costs it incurs, rather than net of them. If no, it reports only its net fee. Either way, the merchants' $1M never enters the income statement.
Underlying goods and services. Reporting the $1M as revenue would require the platform to control the merchandise or services sold to end customers — a completely different question, answered on the goods themselves, not on payments. A marketplace that takes title and bears inventory risk might reach it. A platform that merely processes payments for independent sellers does not.

The practical test: funds owed onward to merchants are a liability, not revenue, whatever the processing conclusion. If a gross-revenue figure includes money the entity is obliged to pay to someone else, the analysis has jumped from one question to the other. This is the mechanism behind several well-known platform revenue restatements, and it is always the same step that is skipped.
ASC 606-10-32-2; 606-10-55-36 through 55-39A.
FactorPrincipal IndicatorsAgent Indicators
Control of servicePlatform sets merchant pricing, controls the payment experience, handles disputesPFaaS provider sets terms; platform is a reseller with no pricing control
RiskPlatform bears chargeback risk on sub-merchants; holds reserve liabilityPFaaS provider bears CB risk; platform has no reserve obligation
Discretion in pricingPlatform marks up from wholesale rate to merchants independentlyPlatform earns a fixed referral or revenue share; can't set its own rate
Inventory/capacityPlatform controls processing capacity and routingPFaaS provider controls routing; platform is a pass-through
Controller Watch-Out — PFaaS Revenue Overstatement
A fast-growing platform using PFaaS records its full GMV (gross merchandise value processed) as revenue, arguing it controls the payment experience. Auditors test the three principal indicators and find the platform cannot demonstrate price-setting authority (Stripe Connect sets the interchange + acquirer markup; the platform only adds a small spread). The platform is an agent. Revenue must be restated from gross GMV to net platform fees — a 97% reduction in reported payments revenue. This scenario has played out at multiple fintech companies during IPO readiness audits. Get the memo written before the auditor asks.
Chapter 13

Volume Definitions
& Mix Risk

Volume is not one number. Auth volume, cleared volume, settled volume, reported volume, and eligible volume are five different figures — and confusing them is the most common source of interchange reconciliation errors in merchant acquiring.

When a business leader says "our volume was $100M last month" they could mean any of five different things, each with a different dollar amount and a different accounting implication. The controller who conflates these numbers produces incorrect interchange accruals, misstated revenue, and unreconciled settlement files. This section defines each precisely and maps them to their accounting triggers.

The Five Volume Definitions

Volume TypeDefinitionWhen It MattersTypical Relationship to Prior
Auth VolumeSum of all authorization amounts approved at T+0, regardless of whether they ever clearFraud monitoring; auth-to-clear conversion rate analysisHighest — includes auths that will never clear (abandoned carts, cancelled stays, failed captures)
Cleared VolumeSum of all transaction amounts submitted for clearing and accepted by the networkRevenue recognition trigger; interchange qualification; period cutoffLower than auth — excludes uncaptured auths; may include amounts not originally authorized (tips, adjustments)
Settled VolumeSum of all amounts included in the network's net settlement calculation for a given processing dayCash receipt timing; settlement receivable; T+1/T+2 accountingTypically matches cleared with 1-2 day lag; may differ due to holds, disputes, adjustments
Reported VolumeVolume reported to the card networks per their reporting requirements; may include or exclude certain transaction typesNetwork assessment calculations; scheme fee basis; network complianceMay differ from cleared due to network-specific volume definitions (Visa vs. MC treat some transactions differently)
Eligible VolumeVolume qualifying for a specific interchange rate, incentive tier, or program (e.g. debit issued by a Regulation II–covered issuer; transactions meeting a program's data and entry-mode requirements)Interchange cost modeling; incentive tier calculations; pricing analysisSubset of cleared volume; varies widely by merchant portfolio characteristics
Close Risk — Volume Cutoff
Revenue recognition uses cleared volume (clearing date in period). Cash receipt uses settled volume (settlement date). At month-end, there will always be cleared-but-not-settled transactions creating a settlement receivable. The size of this receivable = cleared volume in last 1–2 business days × (1 − MDR%) approximately. If your settlement receivable balance doesn't match this estimate, investigate before closing.

Mix Risk — How Card Mix Destroys Margin

Mix risk is the interchange cost impact of a shift in the composition of cards used to transact at a merchant portfolio, with no change in GTV or MDR pricing. It is the most commonly missed variance component in acquirer margin analysis and a frequent source of unexplained P&L deterioration.

Mix Risk Example — $100M Portfolio, Q1 → Q2
Q1 Card Mix: 40% consumer debit (0.60% avg IC) + 60% consumer credit (1.80% avg IC)
Q1 Blended IC Rate: (40% × 0.60%) + (60% × 1.80%) = 0.24% + 1.08% = 1.32%
Q1 IC Cost: $100M × 1.32% = $1,320,000

Q2 Card Mix: 30% consumer debit + 70% consumer credit (merchants add online channel)
Q2 Blended IC Rate: (30% × 0.60%) + (70% × 1.80%) = 0.18% + 1.26% = 1.44%
Q2 IC Cost: $100M × 1.44% = $1,440,000

Mix Effect: $1,440,000 − $1,320,000 = $120,000 incremental IC cost
MDR unchanged. GTV unchanged. Pure mix — invisible without BIN-level analysis.

Decomposing the Interchange Variance Bridge

A complete interchange cost variance bridge has three components — volume, rate, and mix. Most controllers only show two. The missing mix component is systematically misattributed to "rate" when it's actually portfolio composition.

Full Three-Way Interchange Variance Bridge
Total IC Variance = Volume Effect + Rate Effect + Mix Effect

V = volume, mᵢ = category share, rᵢ = category all-in rate. A = actual, B = budget.

Volume = (V_A − V_B) × Σ(m_Bi × r_Bi)
Rate    = V_A × Σ[m_Bi × (r_Ai − r_Bi)]   ← budget mix held fixed
Mix     = V_A × Σ[(m_Ai − m_Bi) × r_Ai]   ← actual rates applied

Volume + Rate + Mix = Actual cost − Budget cost, exactly.

Requires category shares to sum to 1 in both periods and consistent treatment of
per-item fees. Data: BIN-level detail by card type from the network clearing file,
mapped to interchange tier categories.
Name Which Vector Is Held Fixed — or the Bridge Will Not Tie
A rate effect written loosely as "actual rates − budget rates, times actual GTV" alongside a mix effect written as "actual blended − budget blended" leaves the weighting unspecified in both terms. Depending on what a reader assumes, the pair can double-count rate movements, omit the rate/mix interaction entirely, or both — and the bridge stops summing to the actual variance.

The decomposition above is sequential: the rate term holds budget mix fixed while rates move, and the mix term applies actual rates while shares move. That ordering assigns the rate/mix interaction to mix, and it reconciles exactly. Other conventions are equally valid — actual mix for rate and budget rates for mix assigns the interaction the other way, and a symmetric convention splits it — but the convention must be stated and applied consistently period to period, or your bridges are not comparable across months.

And beware of stacking this on a two-factor bridge. As Chapter 9 sets out, a two-factor volume/blended-rate bridge is already complete. Mix must replace part of that blended-rate effect, never be added to it. Whichever form you choose, verify the components sum to the actual variance before the bridge is used — that check, not the formula's appearance, is what proves it.
Independent algebraic verification; ASC 250-10-20 for calculation-error context.
Volume MetricData SourceController UseReconciliation Target
Auth VolumeAuthorization host / internal processing systemAuth-to-clear conversion; fraud rate denominatorAuth log system; no GL tie
Cleared VolumeNetwork clearing fileRevenue recognition; interchange accrual; period cutoffRevenue subledger; GL revenue line
Settled VolumeNetwork settlement file + bank statementSettlement receivable; cash receipt timingBank statement; settlement receivable GL
Reported VolumeNetwork billing statements (CBS/MCBS)Scheme fee accrual basisCBS/MCBS billing; scheme fee expense GL
Eligible VolumeNetwork settlement file + interchange qualification flagsInterchange tier analysis; incentive tier trackingInterchange cost sub-ledger by tier
KPIs to Track Weekly
Auth-to-Clear Rate: Cleared Volume / Auth Volume. Healthy: >96%. Below 90% indicates capture failures, abandoned carts, or system issues — each has different revenue and IC implications.

Downgrade Rate: EIRF + Standard Volume / Total Cleared Volume. Target <2%. Every 1% of $100M in volume hitting Standard rate instead of CPS/Retail costs ~$11,900 in excess interchange.

Debit Mix %: Debit Volume / Total Volume. Higher debit % = lower interchange cost. Shift of 10 pts from credit to debit on $100M = ~$120K IC cost reduction annually.
🔍 Controller Lens — Volume Definitions & Mix Risk
WHAT DRIVES EACH VOLUME TYPE?Auth volume = terminal/gateway activity. Cleared volume = merchant batch submission. Settled volume = network net settlement. Each has a different system of record and a different accounting trigger.
SOURCE OF TRUTHAuth volume: authorization host. Cleared volume: the network clearing file (primary accounting document). Settled volume: bank statement. Reported volume: CBS/MCBS billing statement.
TIMINGRevenue cutoff = cleared volume by clearing date. Cash = settled volume by settlement date. Scheme fees = reported volume per billing. NEVER use auth volume for revenue or cost calculations.
KEY RISKMix shift from debit to rewards credit adds IC cost with no MDR change. Auth-to-clear rate drops → revenue leakage. Reported volume differs from cleared volume → scheme fee accrual built on wrong base.

Controller Checklist — Volume Definitions

Volume Reconciliation Controls
□ Revenue recognition uses cleared volume (clearing date), not auth or settled volume
□ Auth-to-clear rate calculated weekly by MCC — flag MCCs below 95%
□ Scheme fee accrual uses reported volume (CBS/MCBS definition), not cleared volume
□ IC cost model uses eligible volume by card tier (debit/credit/rewards/commercial)
□ Card mix breakdown pulled monthly from settlement file BIN data
□ Mix effect calculated separately from rate effect in interchange variance bridge
□ Durbin-eligible debit volume identified and IC modeled at capped rate ($0.21 + 0.05%)
□ Any volume definition change (new product, new MCC) documented before first booking

Why Volume Definitions Matter for Contracts

Merchant agreements define pricing based on volume — and the volume definition in the agreement may not match any of the five technical definitions above. A common contract term: "MDR applies to net processed volume." Does "net" mean cleared volume? Settled volume? GTV minus refunds? The controller must map every contract pricing term to a specific technical volume definition and ensure the billing system applies the correct base. A 2% error in the volume base is not a percentage of the merchant's volume — it is a percentage applied through the fee rate, over however many periods the error runs.

Size a Billing-Base Error Correctly — and State the Period
Billing error = volume × base-error % × contractual fee rate × number of periods
On a $50M monthly merchant with a 2% base error, the annual variance is:

  $50M × 2% × 1.75% × 12 = $210,000 (Scenario A pricing)
  $50M × 2% × 2.30% × 12 = $276,000 (Scenario B pricing)

A figure like "$100K/year" omits the fee rate entirely — $50M × 2% = $1M is a volume difference, not a billing difference. The merchant is billed a rate on that volume, so the variance is the rate applied to it. Omitting the rate understates the error by roughly half here, and by more at richer pricing.

The same discipline applies to every "annual" figure in this chapter. A 12-bp mix effect on $100M of volume is $120,000 per $100M processed — it becomes an annual number only if $100M is the annual volume. If $100M is monthly, the annual effect is $1.44M. Always state the volume period alongside the rate; a bps figure multiplied by an unstated base is not reviewable, and this is the single most common way a contract or variance number gets quoted an order of magnitude wrong.
ASC 606-10-32-2.

Journal Entry — Why Volume Type Matters for Cutoff

Auth Volume vs. Cleared Volume — Cutoff Contrast
December 31 end of day: $5M authorized, $3M cleared, $2M auth-not-yet-captured

CORRECT — Revenue recognition on cleared volume only ($3M, Scenario A rates):
Dr Settlement Receivable                $2,954,100  ($3M − IC $42,000 − scheme $3,900)
Dr Interchange Expense                   $42,000    (1.40%)
Dr Scheme Fee Expense                     $3,900     (0.13%)
  Cr Merchant Payable                       $2,947,500  ($3M − MDR $52,500)
  Cr MDR Revenue                            $52,500    (1.75%)
Dr = $3,000,000 · Cr = $3,000,000 ✓ · margin $6,600 (22 bps)

WRONG — Revenue on auth volume (ASC 606 violation):
Would recognize $87,500 revenue ($5M × 1.75%) — $35,000 overstatement.
$2M of authorized transactions may never clear. Recognizing revenue on them
violates ASC 606 — the performance obligation is not satisfied at authorization.
Estimate Each Balance From Its Own Cash Flow
A cutoff entry can balance and still put the wrong number in both balance-sheet accounts. Deriving the receivable as "$3M × net settlement rate" and then plugging the merchant payable produces a journal that foots — at $2,985,900 — while understating the receivable and the payable by $14,100 each. The columns agree because the same wrong rate drove both sides.

The two balances answer different questions and are computed from different rates:

Settlement receivable = what the network will pay you = GTV less fees withheld (1.40% + 0.13%) = $2,954,100.
Merchant payable = what you owe the merchant = GTV less MDR (1.75%) = $2,947,500.

Using the MDR rate to estimate the network receivable applies the merchant's pricing to the network's obligation — two unrelated contractual cash flows. The tell is the same as in Chapter 1: the two balances should differ by exactly the recognized margin ($2,954,100 − $2,947,500 = $6,600). If they differ by anything else, or if the entry foots to something other than GTV, a rate has been used on the wrong leg.
ASC 606-10-32-2 and 45-4; ASC 210-20-45-1.
Failure Scenario — Settlement Date Used Instead of Clearing Date
What happens: The billing system posts revenue on settlement date (T+2) rather than clearing date. December 30 and 31 clearing — both inside the period — does not settle until the first business days of January, so $6.5M of December GTV posts to January.

Note the dates carefully. The displaced volume has to be clearing that occurred within December. Transactions clearing on January 1 and 2 belong to January under any policy, so they illustrate nothing — there is no misallocation to correct. The error exists only where in-period clearing is pushed out by a settlement-date trigger, and an example built on the wrong dates teaches the opposite of the control.

P&L impact: December MDR revenue understated by $113,750 ($6.5M × 1.75%). January overstated by the same. If material, period-end restatement risk. At minimum, a SOX control deficiency — revenue recognition in the wrong period.

Control: The clearing date field in the network clearing file is the authoritative accounting date. Configure the revenue posting system to use clearing date, not settlement date. Verify this configuration annually and after any system changes.
Chapter 14

Network Reporting
(Visa / Mastercard)

How Visa and Mastercard calculate, bill, and audit assessment fees — accrual vs. invoice timing, quarterly true-ups, compliance program fees, and what controllers must build to stay ahead of billing surprises.

Visa and Mastercard are not just transaction routers. They are the regulatory and economic infrastructure of card payments — setting rates, enforcing rules, billing fees, and fining non-compliance. For the acquiring controller, the card networks operate on their own billing cycle — the invoice arrives weeks after the economic event, the amount is largely non-negotiable, and reconciling it back to internal volume data is the controller's responsibility. Understanding their billing mechanics is essential to accurate accruals and clean audits.

The Billing Hierarchy

Visa Consolidated Billing Statement (CBS)

Monthly statement covering all Visa acquirer fees: assessment, NABU, APF, FANF, ISA, misuse of auth, zero floor limit, and other per-item fees. Typically received 15–20 days after month-end. This is the primary reconciliation document for Visa scheme fee expense. Every line must map to your accrual model.

Mastercard MCBS

Mastercard's equivalent monthly billing. Covers acquirer assessment, network access fees, cross-border fees, and compliance program fees (ECP / EFM). Same 15–20 day lag. The MCBS line item structure differs from Visa CBS — maintain separate accrual models by network, not a blended estimate.

Quarterly Supplemental Billings

Both networks bill certain fees quarterly — digital enablement/token fees, network integrity fees, some compliance program fees. These arrive 30–45 days after quarter-end. If you only accrue monthly network fees, you will miss these entirely until Q4 or year-end when they arrive in a lump sum.

Annual / Ad-hoc Billings

Registration fees (ISO registration, PayFac certification), audit and investigation fees, and extraordinary compliance assessments may arrive without a regular cycle. These are the highest-risk items for P&L surprise — but a percentage cushion is not the answer. See the note below.

A 5–10% Cushion Is Not an Accrual
A percentage buffer "to absorb" fees that might arrive is a reserve against the possibility of future costs. It records no identified obligation, has no measurement basis, and is a cookie jar by construction — it smooths good months into bad ones and will be treated as an earnings-management indicator when an auditor traces it to its support and finds none.

The discipline runs in both directions, and this chapter currently errs on each side:

Accrue what is incurred, even if unbilled. Fees arising from activity that has already occurred are liabilities now, whether or not an invoice has arrived. Estimate them from the fee schedule and your own activity data — that is an incurred-but-unbilled accrual with a real basis, not a cushion.
Accrue probable and estimable contingencies — do not wait for the notice. Elsewhere this chapter says to accrue a compliance fine only when notice is received. If an obligation is already probable and reasonably estimable — a breached threshold with a published assessment, a known PCI failure — the accrual is required then, and the notice merely confirms it. Where a loss is reasonably possible but not probable, disclose it rather than booking it.
Keep everything else out of the GL. Unidentified future fees that might arise belong in forecasting and scenario planning, not in an accrual account.

The real control is coverage, not cushion. A percentage buffer exists to compensate for an incomplete fee inventory. Fix the inventory instead: every fee code you have ever been billed, its cycle and basis, with a standing process for researching any new line that appears on a statement. A complete inventory removes the need for the cushion — and unlike the cushion, it tells you what the money was for.
ASC 450-20-25-2 (accrual criteria) and 450-20-25-8 (general or unspecified business risks are not accruable).

Assessment Fee Calculation Logic

Understanding exactly how networks calculate each fee line is the prerequisite to building an accurate accrual. Networks apply rates to different volume bases — getting the base wrong means your accrual is wrong even if the rate is right.

FeeNetworkRateVolume BaseAccrual Method
Acquirer AssessmentVisa0.13%Settled credit volume (domestic)Monthly: settled credit GTV × 0.13%
NABUVisa$0.0195/authAuthorization countMonthly: auth count × $0.0195
APFVisa$0.025/itemCleared credit transaction countMonthly: cleared credit count × $0.025
FANFVisaTiered by MID volumePer active MID per monthMonthly: active MID count × tier rate — update when MIDs change
ISAVisa0.45–0.80%Cross-border transaction volumeMonthly: cross-border GTV × applicable ISA rate
Acquirer AssessmentMastercard0.13%Settled credit volumeMonthly: settled credit GTV × 0.13%
Network Access FeeMastercard$0.0195/txnTransaction countMonthly: cleared count × rate
Digital Enablement FeeBothVariableToken volumeQuarterly accrual: prior quarter bill / 3 × volume growth factor
VAMP assessmentsVisaPer current published program materialsCounts breaching the applicable VAMP ratioAccrue when the obligation is probable and estimable; base on your own breach forecast
ECP / EFM assessmentsMastercardPer current monitoring and pricing resourcesEnrolled merchant portfolioAccrue as soon as merchant is enrolled in program

Accrual vs. Invoice — The Controller's Operating Model

The core challenge: scheme fees are incurred daily (every transaction generates an assessment) but billed monthly or quarterly. The controller must accrue the full amount by period-end and true-up when the invoice arrives. The accrual error compounds if any of these are wrong: the rate, the volume base, the fee category coverage, or the quarterly fee estimate.

Monthly Scheme Fee Accrual Build — $100M GTV, 1.54M transactions
✗ The build as commonly written — every variable line on the full base:
Visa assessment: $100M × 0.13% = $130,000
Visa NABU: 1,540,000 × $0.0195 = $30,030  ← NABU is a Mastercard fee
Visa APF: 1,540,000 × $0.025 = $38,500
Visa FANF: 500 MIDs × $5.00 = $2,500
ISA (cross-border 5% of GTV): $5M × 0.45% = $22,500
Mastercard assessment: $100M × 0.13% = $130,000  ← "assumes 50/50 split"
Mastercard network access: 1,540,000 × $0.0195 = $30,030
Quarterly digital enablement (1/3 of $90K): $30,000
Total: $413,560 — the addition is right; the bases are not.

✓ Same lines with volume and counts allocated 50/50 by network:
Visa assessment: $50M × 0.13% = $65,000
Visa APF: 770,000 × $0.025 = $19,250
Visa FANF (fixed, per MID): $2,500
ISA: $2.5M × 0.45% = $11,250
Mastercard assessment: $50M × 0.13% = $65,000
Mastercard NABU: 770,000 × $0.0195 = $15,015
Mastercard per-auth equivalent: 770,000 × $0.0195 = $15,015
Quarterly accrual (fixed): $30,000
Illustrative total: $223,030

A mechanical sensitivity only — not a tariff estimate. See below.
The Addition Was Never the Problem — the Bases Were
Checking that eight fee lines sum correctly validates nothing if each line is computed on the wrong volume. Here both networks are charged on the full $100M and the full 1.54M transaction count, immediately after the build states a 50/50 split. The portfolio is effectively billed twice, and the total is roughly 85% too high against the allocated figure.

An over-accrual of this shape is not self-correcting. It survives a reasonableness check (the arithmetic is right), survives a trend review (it is consistently wrong), and only surfaces at the billing true-up — by which point several months of overstated cost of revenue have been reported.

Allocate before you apply a rate. Split volume and counts by network first, then by product, message type and geography as each fee requires, and only then apply the rate. Specifically:

Per-item fees need counts, not volume — and the right count. An authorization-based fee runs on authorization counts; a clearing-based fee on cleared items. They are different populations, and using one for both is a second base error hiding inside the first.
Cross-border fees need the cross-border subset, split by the applicable geography and currency treatment — not a flat percentage of total GTV.
Fixed fees do not scale: per-MID and quarterly amounts stay whole when volume is allocated. Halving them is as wrong as not allocating the variable lines.

The $223,030 above is a sensitivity, not an answer. It shows what allocation alone does to the total. It is not a valid accrual, because the underlying fee mapping still needs fixing — NABU is Mastercard's Network Access and Brand Usage fee and does not belong on a Visa line at all (see Chapter 4), and the cross-border inputs need real geography data. Fix the mapping and the inputs, then rebuild from your own billing schedule.
Arithmetic; Visa Core Rules §1.11.1; Mastercard Security Rules and Procedures §8.3 and current billing resources.
Journal Entry
Dr Scheme Fee Expense       [accrual per your allocated build]
  Cr Scheme Fee Payable     [same]

Book only fees not already expensed elsewhere — see the cutoff overlap
control in Chapter 9.

True-Up Process When Billing Arrives

Controller Watch-Out — FANF Tier Jumps
The Fixed Acquirer Network Fee (FANF) is tiered by monthly volume per MID — low-volume MIDs pay less, high-volume MIDs pay more. When a merchant's volume grows across a tier threshold mid-year, the FANF charge jumps — sometimes by 10x for that MID. If your FANF accrual model uses prior-month actuals without a volume-tier refresh, you will systematically under-accrue for growing merchants. Run a FANF tier analysis quarterly and update the accrual model inputs accordingly.
Audit Evidence — Network Reporting Controls
SOX documentation for scheme fee accruals requires: (1) documented methodology for each fee category, (2) evidence of monthly accrual calculation with volume inputs sourced from the processing system, (3) evidence of billing receipt and comparison to accrual, (4) approval of true-up entries by controller or designee, (5) quarterly review of accrual model adequacy including review of prior-period true-up history. An accrual model with consistently large true-ups is a control weakness regardless of whether the entries are ultimately correct.
🔍 Controller Lens — Network Reporting (Visa/MC)
WHAT CREATES THE LIABILITY?Every cleared transaction accrues assessment, NABU, APF simultaneously. FANF accrues monthly by active MID. ISA accrues on cross-border volume. All create Scheme Fee Payable before billing arrives.
SOURCE OF TRUTHCBS (Visa) and MCBS (Mastercard) are the authoritative billing documents. Your accrual is an estimate. The bill is the fact. Reconcile every line item — not just totals.
TIMINGMonthly fees: billed 15–20 days post-month. Quarterly fees (digital enablement, integrity): 30–45 days post-quarter. Annual/ad-hoc: unpredictable. Accrue 1/3 of quarterly estimate monthly.
KEY RISKNew fee categories not in accrual model. FANF tier jump not refreshed. Quarterly fees creating Q4 spike. VAMP / ECP / EFM enrollment not accrued, or modeled on retired program definitions. Misclassifying network incentives.

Controller Checklist — Network Reporting

Network Billing Close Controls
□ Accrual model covers all CBS fee categories: assessment, NABU, APF, FANF, ISA, misuse of auth
□ Accrual model covers all MCBS fee categories: assessment, network access, cross-border, ECP / EFM
□ Monthly accrual vs. prior month billing variance documented if >5%
□ Quarterly fee accrual driven by the obligation incurred (not automatically 1/3) of prior quarter actual, adjusted for volume trend
□ CBS/MCBS received — every line item mapped to accrual model before true-up posted
□ Any new fee category in billing researched and added to accrual model
□ VAMP / ECP / EFM enrollment tracked — assessments accrued for enrolled merchants on the current published schedules
□ FANF tier analysis run quarterly — MID count by volume tier current
□ Network incentive classified per ASC 705-20 — generally reduces purchase cost, unless a distinct service to the network applies (Ch. 12)

Compliance Programs — Controller Cost Awareness

The Programs Were Renamed and Restructured — Models Built on the Old Ones Are Measuring Nothing
Visa consolidated VDMP and VFMP into VAMP; Mastercard's dispute monitoring is ECP (ECM and HECM categories), with EFM covering fraud separately. An accrual model still keyed to the retired programs is not merely using stale numbers — it is computing a ratio the networks no longer assess.

The constructions differ in ways a threshold swap cannot fix:

VAMP is count-based. It measures TC40 fraud plus TC15 dispute counts against settled CNP transaction counts, subject to exclusions. A model computing a dollar-weighted chargeback rate is not approximating VAMP; it is measuring a different quantity. Where the fact sheet's acquirer-eligibility condition is met, the excessive-merchant threshold is 150 bps effective 1 April 2026 alongside a minimum monthly fraud-and-dispute count, for AP, Canada, EU and U.S. — acquirer-level thresholds and other regions differ.
ECP's ratio has a period offset. It compares current-month chargebacks to prior-month transactions. A same-month ratio will not reproduce it, and the difference is largest exactly when it matters — a merchant whose volume is falling while disputes persist breaches sooner than a same-month calculation predicts.
EFM is assessed separately from ECP. A merchant can breach one and not the other, so a single combined "excessive chargeback" trigger will miss cases.

Do not model legacy fine schedules. Flat monthly tiers and per-dispute amounts from the old programs are not substantiated as current. Mastercard's current merchant rulebook directs precise thresholds and assessments to its monitoring and pricing resources — take them from there rather than from memory, and never certify an old table as current.

Also keep the compliance trigger separate from the accounting trigger. Crossing a monitoring threshold informs your estimate; it does not by itself establish a probable and estimable obligation under ASC 450, and conversely an obligation can be probable and estimable before any notice arrives.
Visa VAMP fact sheet; Visa Core Rules §10.4.3.1; Mastercard Security Rules and Procedures — Merchant Edition §8.3; Mastercard compliance programs.
ProgramNetworkTriggerCost StructureAccrual
VAMP (Visa Acquirer Monitoring Program)VisaCount ratio: TC40 fraud + TC15 disputes ÷ settled CNP transactions (TC05), with defined exclusionsPer current published program materials — legacy per-dispute fine tables are not currentAccrue on enrollment using the applicable current schedule and your own breach forecast
ECP — ECM / HECM categoriesMastercardCurrent-month chargebacks ÷ prior-month transactionsPer current Mastercard monitoring and pricing resourcesAccrue on enrollment; note the ratio's period offset when forecasting
EFM (fraud monitoring)MastercardFraud thresholds, assessed separately from ECPPer current Mastercard resourcesAssess separately — a merchant can breach one program and not the other
TC40 / SAFE ReportingBothNetwork fraud reporting requirementPer network materialsAssess under ASC 450 when an obligation becomes probable and estimable — do not wait for the notice if it already is
Data Security Compliance (PCI DSS)BothNon-compliance with PCI DSS standardsPer network materialsSame ASC 450 test — the notice is evidence, not the trigger
Chapter 15

FTP &
Balance Sheet Mechanics

How the balance sheet drives payments profitability — settlement receivables, merchant payables, cardholder receivables, float, and Funds Transfer Pricing (FTP) as the hidden P&L lever most controllers ignore.

Most payments P&L discussions focus on the income statement: MDR revenue, interchange cost, scheme fees, net margin. But the balance sheet is where the real economics of payments live. Settlement timing creates float. Float is investable. Cardholder receivables generate interest income. Merchant payables represent short-term funding obligations. FTP (Funds Transfer Pricing) is the internal mechanism banks use to allocate the cost and benefit of this balance sheet activity to the businesses that generate it. At a bank-owned acquirer, FTP-allocated float income and funding costs can represent 20–30% of total acquiring contribution in a normal rate environment — a material component that is invisible to controllers who focus only on fee income and interchange spreads.

Why This Matters for the Acquiring Controller
At an independent acquirer (non-bank), FTP is less formal but float economics still exist — the time between receiving settlement from the network and funding the merchant is real cash earning real interest. At a bank-owned acquirer, FTP formally allocates the cost of funding merchant payables and the benefit of float to the acquiring business. Getting FTP right means the acquiring P&L reflects true economic contribution — not just fee income.

The Payments Balance Sheet — Four Key Positions

Balance Sheet ItemNatureSize DriverP&L ConnectionFTP Treatment
Settlement ReceivableAsset — amount due from network after clearing, before cash receiptDaily cleared volume × net settlement rate × float days (1–2 days)Clears to cash on settlement; no direct income but represents float assetEarns FTP credit at short-term rate for days outstanding
Merchant PayableLiability — amount owed to merchants after MDR deduction, before fundingDaily cleared volume × (1 − MDR%) × funding float daysReduces to zero when merchant DDA funded; net of reserve holdsCharged FTP debit at short-term rate for days outstanding
Merchant Reserve LiabilityLiability — funds withheld from merchant as risk bufferRolling % of monthly volume × holding periodInvestable by acquirer during hold; earns float incomeEarns FTP credit at short-term rate for the holding period
Cardholder Receivable (Issuing)Asset — outstanding credit card balances owed by cardholdersAverage revolving balance = monthly spend × (% revolving) × (1 − payment rate)Generates interest income (largest issuer income line); subject to CECL reserveCharged FTP debit at funding curve rate; spread = net interest margin

Float Economics — The Full Model

Float is the investable cash that exists because settlement timing creates temporary balances. For an acquirer, there are two types: receive float (settlement receivable earns interest while in transit from network) and pay float (merchant payable is a temporary source of funds between receipt and disbursement). In a rising rate environment, float becomes a meaningful P&L contributor.

Float Economics — Full Build at $100M Monthly GTV, 4.50%
Signs follow the cash: an asset awaiting collection consumes funding;
cash retained before disbursement supplies it.


Settlement receivable — a use of funds (1.5 days)
Average balance = $100M × (1 − 1.40% − 0.13%) / 30 × 1.5 = $4,923,500
Annual funding cost = $4,923,500 × 4.50% = ($221,558)

Merchant payable — a source of funds (0.5 days)
Average balance = $100M × (1 − 1.75%) / 30 × 0.5 = $1,637,500
Annual benefit = $1,637,500 × 4.50% = $73,688

Reserve balances — a source of funds, to the extent unrestricted
Steady state = 3 monthly cohorts under a 90-day hold at 10%
  = $100M × 10% × 3 = $30,000,000  (not $10M — see below)
Annual benefit = $30,000,000 × 4.50% = $1,350,000

Net annual float contribution: $1,202,130
On $1.2B annual GTV = 10.02 bps
Classification: interest income (ASC 835) — not operating revenue
Three Errors That Move This Number by Millions
1 · A 90-day rolling reserve holds three cohorts, not one. Withholding 10% of $100M each month and releasing after 90 days means three months of withholding are outstanding at any time. Steady state is $30M, not $10M — $10M is the balance at the end of the first month, before the second and third cohorts accumulate. Using the first-month figure as steady state understates the reserve balance by two-thirds and the float benefit by $900,000 a year. (The same $10M error recurs in Chapter 16's master flow.) If your program is capped rather than rolling, say so and show the cap — but then it is not a 90-day rolling reserve.

2 · Do not apply the lag twice. The balance formula already divides monthly volume by 30 and multiplies by the lag days — the result is an average balance. Multiplying that balance by the lag again, or by days/365 × 365, double-counts the timing. Written as "$4.86M × 4.5% × 1.5" the receivable line would give $328,050 rather than $218,700; written with "× 0.5" the payable line gives $36,844 rather than $73,688. In both cases the displayed answer silently drops the extra multiplier — which means the formula on the page has never actually been evaluated as written. An average balance times an annual rate is already an annual figure.

3 · The stated receivable balance was arithmetically wrong. $100M × 98.47% ÷ 30 × 1.5 is $4,923,500, not $4,862,167 — a $61,333 understatement that flows through to every figure derived from it.

And only genuinely investable cash belongs here. Per Chapter 5, reserve balances that are contractually, legally or regulatorily restricted are not available to invest, whatever their size. Run the restriction analysis before crediting the $30M with a yield; where part is restricted, model only the remainder and disclose the rest.
Arithmetic and dimensional analysis; ASC 405-20-40-1; ASC 230-10-50-7 (restricted cash).

FTP — Funds Transfer Pricing Framework

FTP is the internal rate a bank's treasury charges or credits its business units for the use of balance sheet. For the acquiring business within a bank:

Getting the Signs Backwards Inverts the Business's Financing Economics
The intuitive framing — "the receivable earns us interest, the payable costs us" — reverses the actual cash mechanics and will produce an FTP contribution with the wrong sign on two of three lines.

Work from the cash, not the balance sheet caption. An asset you have not yet collected is money you are out of pocket for: it consumes financing until it converts. A liability you have not yet paid is money still in your hands: it supplies financing until you disburse it. Acquiring is, in float terms, substantially funded by its payables and reserves — which is why the net contribution above is positive despite the receivable line being a cost.

Two further cautions:

FTP rates and signs come from your treasury's approved methodology, not from accounting standards. No ASC paragraph mandates the treatment above; it is the economically coherent default, and your institution's framework governs. Document which you are applying.
FTP is an internal allocation and eliminates on consolidation. It moves P&L between the acquiring business and treasury. It is not external interest income, does not survive into consolidated results, and should never be presented as if it were revenue earned from a third party.
ASC 835-30-35 (interest, where applicable to external instruments); ASC 810-10-45-1 (intra-entity elimination). No ASC mandates FTP signs or rates.
FTP Contribution — $100M Monthly Portfolio, 4.50%
Average balance × annual rate. The lag is already inside the balance —
do not multiply by it again.


FTP charge on settlement receivable:
  $4,923,500 × 4.50% = ($221,558)/yr
FTP credit on merchant payable:
  $1,637,500 × 4.50% = $73,688/yr
FTP credit on reserve balances (unrestricted portion):
  $30,000,000 × 4.50% = $1,350,000/yr

Net annual FTP contribution: $1,202,130
On $1.2B annual GTV = 10.02 bps

Note the denominator: annual contribution must be expressed against annual
volume. Dividing an annual figure by one month's $100M gives 100 bps and is
wrong by a factor of twelve.


Rate sensitivity: at 0%, the entire float contribution disappears. This line is
a rates position, not an operating one — model it separately in the budget.

Cardholder Receivables — Issuer Balance Sheet

For issuers, the cardholder receivable (outstanding credit card balances) is the primary balance sheet asset and the primary income driver. Understanding how it builds, deteriorates, and is reserved is essential for any finance professional at a bank with card issuing operations.

Cardholder Receivable Build — Deliberately Simplified Revolving-Interest Model
This illustrates interest dynamics only. It is not a receivables or CECL model —
see the limitations below before using its shape for either.


Monthly spend: $100M
Share of balances that revolve: 35%
Opening receivable balance: $100M
Monthly payment rate on the opening balance: 15%
Net monthly change ≈ $35M added − ($100M × 15%) = +$20M

Average APR on revolving balances: 22%
Monthly interest ≈ revolving balance × 22% / 12
  Apply the rate only to balances actually carrying interest — not to
  total spend, and not to balances in a grace period.
Two Reasons This Is Not a CECL Model
1 · The receivable is not just the revolving portion. A card receivable arises when a purchase is funded, whether or not the cardholder later revolves. Transactors — who pay in full within the grace period — still create a funded balance the issuer carries until payment, and that balance is a financial asset in scope. Computing a Day-1 provision as "new revolving balance × CECL rate" applies the allowance to roughly a third of the exposure and omits the rest.

2 · A single Day-1 rate is not lifetime measurement. CECL requires a lifetime expected-loss estimate over the contractual term for all in-scope funded balances, remeasured at each reporting date using current information and reasonable and supportable forecasts. A flat percentage applied once at origination is a rule of thumb, not a model — and per Chapter 11, only drawn balances are in scope; undrawn availability that is unconditionally cancellable carries no commitment liability.

To build the real thing you need, at minimum: funded principal by vintage, payment behavior and grace-period assumptions separating transactors from revolvers, the interest-accrual basis, opening/closing/average balances rather than a single point, the lifetime loss estimate, and the re-estimation process each period. Treat the schedule above as an illustration of how balances and interest move, and nothing more.
ASC 326-20-15-2 (scope), 30-2 (measurement) and 35-1 (each reporting date); ASC 310-20.

Journal Entries — Balance Sheet Positions

FTP Journal Entries (Bank-Owned Acquirer)
Signs match the corrected framework above: the receivable is funded (charge),
the payable and reserves supply funding (credits).


FTP charge on settlement receivable (monthly):
Dr FTP Expense — Interest         $18,463
  Cr FTP Payable — Treasury          $18,463  ($4,923,500 × 4.50% / 12)

FTP credit on merchant payable (monthly):
Dr FTP Receivable — Treasury      $6,141
  Cr FTP Income — Interest           $6,141  ($1,637,500 × 4.50% / 12)

FTP credit on unrestricted reserve balances (monthly):
Dr FTP Receivable — Treasury      $112,500
  Cr FTP Income — Interest           $112,500  ($30,000,000 × 4.50% / 12)

Net monthly FTP contribution: $6,141 + $112,500 − $18,463 = $100,178/month
× 12 = $1,202,130/year, tying to the build above ✓

These entries eliminate on consolidation — they allocate P&L between the
acquiring business and treasury, and are not external interest income.

Controller Checklist — FTP & Balance Sheet

Balance Sheet Close Controls
□ Settlement receivable balance validated: all open items within 3 business days of clearing
□ Merchant payable balance supported by merchant sub-ledger
□ Reserve liability roll-forward balanced and tied to individual merchant balances
□ FTP income and expense recorded from treasury FTP system (not manual)
□ Float income classified as interest income — not operating revenue
□ Any balance sheet position with no corresponding transaction detail = open item requiring investigation
□ Rate sensitivity analysis run quarterly: show P&L impact of +100bps / −100bps Fed Funds on float
□ CECL reserve adequacy reviewed: actual loss rates vs. model inputs updated quarterly
Controller Watch-Out — Rate Environment Reversal
During 2020–2021 (near-zero rates), float income was negligible and FTP contributions were immaterial. When rates rose sharply in 2022–2023, float income became a material P&L driver for acquirers and issuers holding large balance sheet positions. Controllers who had not built float modeling into their management reporting suddenly had unexplained P&L favorability. Boards asked questions. The controllers who had proactively modeled float economics looked strategic; those who hadn't scrambled to explain. Build the model before you need it.
🔍 Controller Lens — FTP & Balance Sheet Mechanics
WHAT CREATES THE ASSET/LIABILITY?Settlement receivable (asset) from network timing. Merchant payable (liability) until funded. Reserve liability from withheld settlements. Cardholder receivable from credit extended. All four are balance sheet positions, not just P&L.
SOURCE OF TRUTHTreasury FTP system for rate assignments. Bank statement for cash positions. Reserve sub-ledger for liability detail. Card management system for cardholder balances. None of these are optional.
TIMINGFloat income is real-time but recognized monthly. FTP credits/charges allocated monthly from treasury. Rate changes (Fed Funds) flow through immediately — build a rate sensitivity model before rates move.
KEY RISKFloat income classified as operating revenue (inflates take rate). FTP not allocated to acquiring P&L (understates true economics). CECL provision not booked Day 1. Reserve liability earning float income not flowing to acquirer P&L.
Chapter 16

End-to-End
Master Flow

One complete lifecycle — from authorization to closed books. Every GL entry, every timing difference, every system handoff, every accrual. The $100M monthly portfolio model, fully reconciled from T+0 to M+20.

Every section in this handbook covers one piece of the acquiring lifecycle. This section ties them all together in a single, unbroken flow — the way a controller actually experiences the business. Use this as your anchor reference. When something in your close doesn't tie, trace it back to this model and find where the chain breaks.

Standard Model — Used Throughout This Flow
Monthly GTV: $100,000,000 · Daily GTV: $3,333,333
MDR: 1.75% → $1,750,000/month · Interchange: 1.40% → $1,400,000/month
Scheme fees: 0.13% → $130,000/month · Net margin: 0.22% → $220,000/month
Settlement receivable float: 1.5 days · Reserve rate: 10% rolling 90-day

Phase 1 — Authorization (T+0)

The cardholder taps or swipes. The acquirer sends an authorization request to the card network, which routes to the issuer for approval. Approval comes back in under 200ms. No money moves. No accounting entry.

T+0 — Authorization · No GL Entry
Auth request: $100 transaction at a restaurant (MCC 5812)
Acquirer → Visa/MC → Issuer → Approve (auth code returned)
Cardholder's available credit/debit reduced by $100
Acquirer's open authorization log: +1 item, $100
Journal entry: NONE

Controller note: Monitor open auth count daily. Auths not captured within 7 days
(30 for lodging/car rental) expire. No revenue is ever recognized on uncaptured auths.

Phase 2 — Clearing (T+1) — Revenue Recognition Trigger

The merchant closes their daily batch. All captured transactions are submitted to the acquirer's processor, which formats and submits a clearing file to the network. This is the accounting event. Revenue is recognized at clearing — the performance obligation (authorizing and facilitating the payment) is complete.

T+1 Clearing Journal — $3,333,333 Daily GTV (1/30th of $100M)
Daily MDR revenue: $3,333,333 × 1.75% = $58,333
Daily IC expense: $3,333,333 × 1.40% = $46,667
Daily scheme fee: $3,333,333 × 0.13% = $4,333
Daily merchant payable: $3,333,333 − $58,333 MDR = $3,275,000
Daily net settlement receivable: $3,333,333 − $46,667 IC − $4,333 scheme = $3,282,333

Dr Settlement Receivable              $3,282,333
Dr Interchange Expense                 $46,667
Dr Scheme Fee Expense (daily accrual)    $4,333
Note: Most shops run a monthly scheme fee entry (not daily) because networks bill monthly.
Daily accrual shown here is theoretically correct; monthly accrual is standard practice.
  Cr MDR Fee Revenue                     $58,333
  Cr Merchant Payable                     $3,275,000
Check: Dr $3,333,333 = Cr $3,333,333 ✓
Acquirer margin captured: $58,333 − $46,667 − $4,333 = $7,333/day (22 bps)

Phase 3 — Settlement (T+1 to T+2) — Cash Receipt

The card network calculates multilateral net settlement positions for all members. It sends net cash to the acquirer (GTV minus interchange minus scheme fees) via the settlement bank (typically Fed or SWIFT). The settlement receivable converts to cash.

T+1/T+2 — Cash Settlement Journal
Network sends acquirer: Daily GTV − IC − Scheme fees = $3,282,333

Dr Cash — Settlement Account           $3,282,333
  Cr Settlement Receivable                 $3,282,333

Balance sheet after settlement:
Settlement Receivable: $0 (cleared) · Cash: +$3,282,333 · Merchant Payable: $3,275,000
Net cash retained = $7,333 (the acquirer margin — this is the business)

Phase 4 — Merchant Funding (T+1 to T+3)

The acquirer funds the merchant's DDA account net of MDR and any reserve holds. This extinguishes the merchant payable. The reserve withheld becomes a liability that will be held for 90 days and then released (or applied to chargebacks).

T+1–T+3 — Merchant Funding Journal
Merchant payable: $3,275,000
Reserve withheld (10% of daily GTV): $333,333
Net funded to merchant DDA: $3,275,000 − $333,333 = $2,941,667

Dr Merchant Payable                    $3,275,000
  Cr Merchant Reserve Liability          $333,333
  Cr Cash / ACH Payable                   $2,941,667

Reserve build under a 90-day rolling hold at 10%:
  End of month 1: $100M × 10% = $10,000,000  (one cohort)
  End of month 2: $20,000,000  (two cohorts)
  End of month 3 onward: $30,000,000  (three cohorts — steady state)

From month 4, each month's release of the oldest cohort is replaced by the new
withholding, so the balance holds at $30M absent losses or volume change.
Steady State Is Three Cohorts, Not One
"$100M × 10% = $10,000,000" is the balance after the first month, not the steady state. A 90-day hold means three monthly withholdings are outstanding simultaneously: the first is released only as the fourth is withheld. Steady state is $30M — three times the figure carried here and in the ending balance table.

The consequence runs in two directions, and both matter. Understated liability: $20M of merchant funds are missing from the balance sheet, and the sub-ledger will not reconcile to the GL. Understated float: Chapter 15's float model prices this balance, so the error propagates into interest income and any FTP credit derived from it — $900,000 a year at 4.5%.

Check it against the release illustration. An opening balance of $9.7M with a release of the same order is a first-month picture, not a steady-state one. If your flow shows a single cohort being withheld and released with nothing accumulating behind it, the hold period in the model is effectively 30 days, not 90 — reconcile the stated hold period to the cohort count before using either figure.

A capped reserve behaves differently: withholding stops at the cap, so the steady-state balance is the cap, not three cohorts. That is a legitimate alternative — but label it, because it is not a 90-day rolling reserve.
Arithmetic; ASC 405-20-40-1. Coordinates with the float build in Chapter 15.

Phase 5 — Month-End Accruals (M+1 to M+3)

The month closes. Daily clearing entries have been booked throughout. Now the controller runs the accrual layer: cutoff for any cleared-but-not-settled items, full scheme fee accrual, and a reserve roll-forward.

M+1 — Month-End Close Entries
Step 1: Revenue cutoff — last 2 days of clearing not yet settled:
Already booked via daily clearing entries (see Phase 2 above) ✓

Step 2: Full monthly scheme fee accrual (if not accruing daily):
Monthly: $100M × 0.13% = $130,000
Dr Scheme Fee Expense                    $130,000
  Cr Scheme Fee Accrual Payable          $130,000

Step 3: Quarterly network fee accrual (1/3 of quarter):
Quarterly digital enablement estimate: $90,000 ÷ 3 = $30,000/month
Dr Scheme Fee Expense — Quarterly       $30,000
  Cr Scheme Fee Accrual — Quarterly      $30,000

Step 4: Reserve roll-forward check:
Opening reserve + Withheld this month − Released (prior 90-day reserve) − CB applied = Closing
Example: $9,700,000 + $10,000,000 − $9,700,000 − $0 = $10,000,000 closing ✓

Phase 6 — Chargeback & Reserve (Ongoing, Monthly Assessment)

M+3 — ASC 450 Reserve Assessment
Merchant ABC: Monthly GTV $500K, CB rate 0.85%, reserve balance $45,000
90-day CB exposure: $500K × 3 months × 0.85% = $12,750
Reserve coverage: $45,000 / $12,750 = 3.5x (well covered — no accrual needed)

Merchant XYZ: Monthly GTV $200K, CB rate 2.10%, reserve balance $5,000
90-day CB exposure: $200K × 3 months × 2.10% = $12,600
Reserve coverage: $5,000 / $12,600 = 0.40x (BELOW 0.80x threshold)
Recovery estimate: 20% = $2,520
Incremental accrual needed: $12,600 − $5,000 − $2,520 = $5,080

Dr CB / Reserve Expense                 $5,080
  Cr Loss Contingency Liability           $5,080

Phase 7 — Network Billing True-Up (M+10 to M+20)

M+15 — CBS/MCBS Billing Receipt and True-Up
Note: this flow's daily entries withheld scheme fees in settlement, so the only
accrued balance to true up is the $30,000 quarterly portion. Per-item fees such as
the $30,030 below were never accrued in this flow — they are shown to illustrate a
newly identified category, and must be added to the accrual model going forward
rather than trued up against an accrual that does not exist.


Visa CBS received M+15. Actual monthly assessment: $127,400 (accrued $130,000)
Per-item fees billed: $30,200 (no prior accrual in this flow)
New fee category: Network Integrity Fee $4,500 (NOT in accrual model — flag immediately)

True-up entry:
Dr Scheme Fee Accrual Payable          $2,430   (over-accrual: $130K+$30,030 vs $127,400+$30,200)
Dr Scheme Fee Expense — Network Integrity  $4,500  (new fee — no prior accrual)
  Cr Scheme Fee Expense                    $2,430
  Cr Scheme Fee Payable                    $4,500
Action: Add Network Integrity Fee to next month's accrual model.

Phase 8 — Quarterly Fee True-Up (Q+45)

Q+45 — Quarterly Network Fee Billing True-Up
Quarterly digital enablement actual billing: $94,000 (accrued 3 × $30,000 = $90,000)
Variance: $4,000 under-accrued

Dr Scheme Fee Expense                    $4,000
  Cr Scheme Fee Payable                    $4,000
Update quarterly estimate: $94,000 / 3 = $31,333/month for next quarter

Phase 9 — Variance Bridge (M+7)

Monthly Margin Variance Bridge — Actual vs. Budget
Budget: $100M GTV · 1.75% MDR · 1.40% IC · 0.13% Scheme = $220,000 margin
Actual: $103M GTV · 1.73% MDR · 1.43% IC · 0.13% Scheme

Volume Effect: ($103M − $100M) × 0.22% budget margin = +$6,600
MDR Rate Effect: (1.73% − 1.75%) × $103M = −$20,600  (pricing pressure)
IC Rate Effect: (1.43% − 1.40%) × $103M = −$30,900  (mix shift to rewards cards)
Scheme Rate Effect: (0.13% − 0.13%) × $103M = $0
Total: $220,000 + $6,600 − $20,600 − $30,900 = $175,100 actual margin

Management narrative: Volume beat offset by rewards card mix shift costing $31K.
Pricing pressure cost additional $21K. Net: $44,900 below budget.

Full Balance Sheet Position — End of Month

AccountBalanceSourceSupported By
Settlement Receivable$6,564,667Last 2 days clearing not yet settledNetwork settlement file clearing dates
Merchant Payable$6,550,000Last 2 days clearing — recognized but not yet funded, matching the open receivableFunding confirmation reports
Merchant Reserve Liability$30,000,00010% rolling 90-day reserve at steady state (three cohorts)Reserve sub-ledger by merchant MID
Scheme Fee Accrual Payable$30,000Quarterly portion only — the $130,000 monthly was withheld in settlement and is already out of the receivableAccrual model with volume inputs
Loss Contingency Liability$5,080ASC 450 merchant-specific accrualASC 450 assessment worksheet
MDR Revenue (MTD)$1,750,000GTV × 1.75%Processing system clearing file
Interchange Expense (MTD)$1,400,000GTV × 1.40%Network settlement file IC detail
Scheme Fee Expense (MTD)$160,000$130,000 netted in settlement + $30,000 quarterly accruedAccrual model; true-up at M+15
Net Margin (MTD) before loss provision$190,000Revenue − IC − Scheme (incl. quarterly portion)GL reconciled to sub-ledger
Less: ASC 450 loss provision($5,080)Merchant-specific accrual booked in Phase 6ASC 450 assessment worksheet
Net Margin (MTD) after provision$184,920The figure that reaches the P&LGL reconciled to sub-ledger
Three Consistency Checks on the Ending Balance Sheet
A master flow is only useful if one ledger survives every phase. Three places where this one can quietly diverge:

1 · The receivable and the payable move together. If the last two days of clearing have not settled, the $6,564,667 receivable is open — and so is the $6,550,000 merchant payable arising from the same transactions. Showing the receivable open while the payable is zero asserts that merchants were funded before the cash arrived. That may be true, and some acquirers do pre-fund, but then the flow must show the funding source and the additional float cost of carrying it. The two balances should differ by the recognized margin ($14,667), exactly as they do at the transaction level.

2 · A fee is netted or accrued, never both. The daily entries in this flow withhold scheme fees in settlement, so no monthly scheme payable exists at period end — only the $30,000 quarterly portion that was genuinely accrued. Carrying the full $160,000 as a payable would double-count the $130,000 already deducted from the receivable, and that payable would never clear. Whichever model you adopt, carry it through every phase: daily entries, month-end accruals, the true-up, and the ending balance sheet.

3 · Only true up what was actually accrued. A true-up entry that relieves an accrual which was never established — a per-item fee category the flow never booked — creates a debit with no corresponding liability. New fee categories found in billing are new expense in the period identified, plus a change to the accrual model going forward. They are not variances.

And state the margin at the right level. The $190,000 is margin before the ASC 450 loss provision booked in Phase 6. After the $5,080 provision the figure reaching the P&L is $184,920. Both are legitimate numbers; quoting one while labelling it the other is how a close package and the GL end up disagreeing by exactly the provision.
ASC 210-20-45-1 (offsetting); ASC 606-10-25-23 and 32-2; ASC 210-10 (balance-sheet presentation).
🔍 Controller Lens — End-to-End Flow
THE CRITICAL PATHEvery dollar of revenue exists in this chain: Auth → Clearing → Settlement Receivable → Cash → Merchant Payable → Funded. If any link breaks, find it before your auditor does. The chain is deterministic — every amount is calculable from first principles.
THE TIMING TRAPSRevenue = clearing date. Cash = T+1/T+2. Scheme fees = M+15/M+20. Quarterly fees = Q+45. Auditors test cutoff. Controllers own cutoff. These timing differences are not nuances — they are the job.
THE TWO P&L LEVERSVolume drives revenue and IC cost proportionally. Mix (card type) drives IC cost independently of volume. A controller who can't separate these two effects in a variance bridge is guessing at what's driving margin. Don't guess.
THE BALANCE SHEET IS THE BUSINESSSettlement receivable, merchant payable, reserve liability — these are not just balance sheet accounts. They are the operating mechanism of the business. The controller who understands the float, the reserve economics, and the settlement timing owns the P&L story completely.

Where the Flow Breaks — Five Failure Modes

Break 1 — Late Presentment (Phase 2 → Phase 3 Gap)
A merchant submits its clearing file well after authorization and the transaction downgrades. Using the illustrative rates in this example — a qualified rate of 1.58% against a downgrade rate of 2.30%, a 72-bp gap — a $50,000 transaction costs $790 at the qualified rate and $1,150 after downgrade: $360 of incremental cost with no revenue change. That single-transaction arithmetic is correct.

Scaling it is where the error creeps in. If 1% of a $100M monthly portfolio presents late:
$100M × 1% × 72 bps = $7,200 per month
× 12 = $86,400 per year
Not $432K. The larger figure implies either a much greater share of volume affected or a much wider rate gap than the one stated — and a five-fold overstatement in a cost-of-poor-presentment business case will not survive review by whoever owns the remediation budget. Always multiply the rate gap by the share of volume actually affected, and state the volume period.

Two inputs to verify before using this at all. The 1.58% qualified rate is the rate used elsewhere in this handbook for a Mastercard tier, while the downgrade rate quoted is a Visa one — check that both rates come from the same network's schedule before computing a gap between them. And presentment deadlines are set per network, region, MCC and transaction type (Chapter 1): a transaction clearing on day 9 does not automatically downgrade, so establish the applicable window and the qualification requirement that was actually missed rather than assuming a universal 7-day rule.
Arithmetic; Visa U.S. interchange schedule; Visa Core Rules §7.
Break 2 — Settlement File Not Received (Phase 3 Fails)
Network's SFTP delivery of the clearing file fails silently. No cash receipt expected. No revenue recognized. The controller's Layer 1 reconciliation catches it: network portal shows $3.28M cleared, processing system shows nothing. The file needs to be manually re-requested. If this isn't caught by 5pm on T+2, the settlement receivable will be open past its expected clearing date, triggering the >3 day escalation rule.
Break 3 — Reserve Shortfall at Phase 6
Merchant ABC has 90-day CB exposure of $75,000 against a reserve balance of $45,000. Coverage ratio: 0.60x — below the 0.80x threshold. ASC 450 two-condition test: loss is probable (CB rate trending up) and estimable ($75K − $45K − $8K recovery = $22K). Accrual required now. Controller who waits for the CBs to arrive books the loss 60 days late.
Break 4 — Scheme Fee Surprise at Phase 7
CBS arrives with a Network Integrity Fee of $18,000 that has no corresponding accrual. This fee was introduced in Visa's quarterly network bulletin in September. The controller didn't read the bulletin. Result: $18,000 unexpected expense hitting P&L in the true-up month. Management asks why. Controller has no explanation. The fee should have been in the accrual model for three months prior.
Break 5 — Variance Bridge Doesn't Close (Phase 9)
The volume effect + rate effect + mix effect + scheme effect doesn't equal total margin variance. The bridge is off by $42,000. The most common cause: the mix effect was omitted. The controller ran a two-way bridge (volume + rate) and attributed everything else to "rate." In reality, a 10-point shift from debit to rewards cards drove $31,000 of IC cost increase that was invisible in the rate line. The bridge needs three components: volume, MDR rate, and IC mix. If it doesn't close, you haven't found the real driver.

Master Flow Close Checklist

End-to-End Flow — Verification Checklist
Phase 1–2 (Auth → Clearing):
□ Auth-to-clear conversion rate >96% for all MCCs
□ No clearing files older than 7 days unprocessed
□ Revenue recognized on clearing date — not auth date, not settlement date

Phase 3–4 (Settlement → Funding):
□ Net settlement received = GTV × (1 − IC% − scheme%) within $10K
□ All merchants funded within T+3
□ Reserve withheld ties to sub-ledger by merchant MID

Phase 5 (Month-End Accruals):
□ Cutoff verified — accrue only entries not already posted through daily clearing
□ Monthly and quarterly scheme fee accruals posted
□ Reserve roll-forward balanced

Phase 6 (ASC 450):
□ All merchants with CB rate >0.50% assessed
□ All merchants with coverage <0.80x assessed
□ Incremental accruals booked where probable + estimable

Phase 7–8 (Network True-Up):
□ CBS and MCBS received and every line mapped to accrual
□ True-up entries posted with variance documentation
□ New fee categories added to next month's model

Phase 9 (Variance Bridge):
□ Three-way bridge closes: Volume + MDR Rate + IC Mix = Total variance
□ Management narrative explains each driver >$25K
□ Bridge reviewed and approved before P&L package distributed
Chapter 23

BNPL
Controller Framework

Buy Now Pay Later — the accounting framework for acquirers and issuers processing BNPL transactions. ASC 606 recognition, receivable treatment, contra-revenue decisions, reserve methodology, and the P&L impact of deferred pay at scale.

BNPL volume exceeded $300B globally in 2024 and is the fastest-growing payment method in e-commerce. For controllers, BNPL creates accounting questions that traditional card frameworks don't answer: who recognizes the receivable? When does the merchant get paid? How is the BNPL provider's revenue recognised? What reserve is required? The answer depends entirely on where your organisation sits in the BNPL value chain.

The Three BNPL Models — Accounting Differs by Position

ModelExampleWho Funds MerchantWho Holds ReceivableController's Primary Concern
BNPL Provider Funds (Standard)Affirm, Klarna, Afterpay standaloneBNPL provider pays merchant 100% upfront (less merchant discount rate)BNPL provider holds consumer installment receivableIf you're the acquiring bank: MDR on the BNPL transaction. BNPL provider is your merchant. Reserve against BNPL provider insolvency.
Bank-Partner BNPLBank-partnered installment products offered through card railsIssuing bank funds merchant via card railsIssuing bank holds consumer receivableIf you're the issuer: consumer installment receivable on balance sheet. Interest income (if interest-bearing). CECL reserve required Day 1.
Embedded BNPL (PFaaS)Stripe BNPL, Adyen BNPLPlatform/PSP arranges BNPL, third-party fundsThird-party lender holds receivableIf you're the platform: principal vs. agent test for BNPL fee revenue. Are you arranging credit or extending it?

Revenue Recognition — BNPL Provider Perspective

For a BNPL provider (Affirm, Klarna, Afterpay), revenue comes from two sources: the merchant discount rate (MDR charged to the merchant for the BNPL service — typically 2–8%, much higher than card MDR) and consumer fees (late fees, interest on longer-term plans). The scope question comes first, and it is not automatic.

The Merchant Discount May Not Be ASC 606 Revenue at All
Treating the $60 merchant discount as immediate service revenue assumes it is consideration for a distinct service provided to the merchant. Often it is not — it is part of acquiring a financial asset. The provider pays $940 for a $1,000 receivable, and the $60 is the discount at which that asset was originated or purchased.

That distinction changes the accounting entirely:

If it is loan origination or purchase economics, the financial-instrument guidance applies first. ASC 606 expressly excludes financial instruments and related contractual rights from its scope, and origination fees and costs are generally deferred and recognized as a yield adjustment over the life of the receivable under ASC 310-20 — not recognized immediately at merchant funding.
If it is genuinely consideration for a distinct service to the merchant — payment processing, fraud screening, conversion tooling delivered separately from the credit — then ASC 606 applies to that component.
Many contracts contain both. Identify and measure the components rather than routing the whole discount to one answer.

Different BNPL contracts reach different conclusions, and the structure drives it: whether the provider originates the loan or purchases a receivable, whether it bears the credit risk, and what it actually promises the merchant. Establish that before any recognition pattern is chosen. And note the asymmetry — immediate revenue recognition is the aggressive answer, so it is the one requiring the stronger documentation.
ASC 606-10-15-2(c) and 15-4 (scope); ASC 310-20-25-2 and 310-20-35 (origination fees as yield adjustment); ASC 326-20 (credit losses on the resulting asset).
BNPL Provider Revenue Journal — $1,000 Consumer Purchase, 4-Pay
Consumer purchases $1,000 item. BNPL provider pays merchant $940 (6% MDR).
Consumer owes $1,000 in 4 installments of $250 over 6 weeks. No interest (0% APR).

At merchant funding (T+1 from purchase):
Dr Consumer Installment Receivable       $1,000.00
  Cr Cash — Merchant Payment                 $940.00
  Cr Merchant Discount Revenue (ASC 606)  $60.00  (6% MDR — recognized at merchant funding)

ASC 606 performance obligation: Satisfied when BNPL provider pays the merchant.
The consumer payment plan is a separate financial instrument, not a revenue item.

Each $250 installment received:
Dr Cash                                     $250.00
  Cr Consumer Installment Receivable      $250.00

CECL reserve at origination (lifetime loss estimate, e.g., 3%):
Dr Credit Loss Provision                    $30.00
  Cr Allowance for Credit Losses             $30.00

Acquirer Perspective — When BNPL Provider Is Your Merchant

Acquirer Processing BNPL Volume — P&L Impact
BNPL provider (Affirm) is a merchant on your acquiring platform.
Affirm processes $10M/month through your acquirer at standard MDR.

Acquirer accounting: identical to any other merchant.
Dr Settlement Receivable        $9,887,000  ($10M − IC $100,000 − scheme $13,000)
Dr Interchange Expense           $100,000    (Visa/MC card IC on consumer card used)
Dr Scheme Fee Expense             $13,000
  Cr MDR Revenue                    $175,000    (1.75% MDR on $10M)
  Cr Merchant Payable — Affirm    $9,825,000

Controller note: BNPL providers like Affirm are among the largest acquirer
merchants by volume. Their own solvency risk is your reserve risk. A BNPL
provider insolvency creates the same CB exposure as any merchant insolvency —
except at dramatically larger scale. Reserve model must reflect this concentration.

Contra-Revenue in BNPL — The Merchant Incentive Question

Some BNPL arrangements include merchant incentives — the BNPL provider pays the merchant a bonus for driving consumer adoption. Under ASC 606, these payments to merchants may be contra-revenue (if they represent a price concession on the MDR) or marketing expense (if the merchant is providing a distinct advertising/promotional service).

Payment TypeClassificationTest
Volume bonus to merchant for BNPL adoptionContra-revenue (variable consideration)Does the merchant provide a distinct service worth the bonus amount? If no → contra-revenue reduces MDR revenue
Merchant co-marketing agreement (logo on checkout page)Marketing expenseMerchant provides identifiable advertising service. FMV of that service = expense. Excess above FMV = contra-revenue.
Risk-sharing payment (merchant absorbs first-loss on defaults)Reduction of credit loss expenseMerchant guarantees reduce BNPL provider's expected credit loss. Recorded as contra to provision, not revenue.
Failure Scenario — BNPL Provider Insolvency (2024-Style)
What happens: A mid-size BNPL provider processes $50M/month through your acquiring platform. They have a 10% rolling reserve ($5M). The BNPL market tightens, funding dries up, and the provider files for bankruptcy in March. In April and May, consumers dispute $8M in transactions — delivered goods but consumers claim credit wasn't properly extended. Your reserve covers $5M. Gap: $3M incremental exposure.

The compounding risk: BNPL CBs often arrive 90–120 days after transaction (consumers dispute installment charges, not the original purchase). Your 90-day reserve was undersized for the BNPL dispute timeline. Standard card CB window models are wrong for BNPL — the dispute window is effectively longer because consumers can dispute individual installments as they're charged.

Control: size the reserve horizon to the evidenced dispute tail for your own BNPL volume, derived from condition-specific dispute windows in the applicable network rules and your actual dispute-arrival distribution. A "150 days" figure is an illustrative extension of the 90-day default, not a rule — the right number depends on the dispute conditions your BNPL volume actually attracts and may be shorter or considerably longer. Monitor provider financial condition on a defined cadence and trigger a reserve adequacy review on any indication of stress.

Treat this scenario as hypothetical. The insolvency outcomes, the dispute allocation and the concentration figures above are constructed to illustrate the mechanics. Do not carry the specific numbers into a memo, and do not assume disputes resolve as described — outcomes follow the applicable network rules and the facts of each case.
🔍 Controller Lens — BNPL
WHAT CREATES THE ASSET?If you are the BNPL provider or issuing bank: the consumer installment receivable created at merchant funding. If you are the acquirer: a settlement receivable created at clearing — same as any merchant. The BNPL structure doesn't change the acquiring P&L mechanics.
SOURCE OF TRUTHMerchant processing agreement (MDR rate). BNPL receivable ledger (installment schedule). CECL model (lifetime loss estimate). All three are different systems that may not talk to each other — build the reconciliation bridge explicitly.
TIMINGMDR revenue: recognized at merchant funding (performance obligation satisfied). Consumer installment: financial instrument, not revenue. Interest income (if any): accrues daily. CECL provision: Day 1 of consumer receivable creation. Dispute window: derive from the applicable condition-specific rules and your own arrival data, not a generic range.
KEY RISKBNPL merchant concentration in your acquiring portfolio. Dispute timeline potentially longer than a standard 90-day reserve model assumes — evidence it rather than assuming either way. Principal vs. agent misclassification (platform recognizes gross BNPL volume when it should recognise net fee). CECL model using card loss rates on BNPL receivables (wrong — BNPL default rates are structurally different).
Controller Tools

Controller
Scenario Tools

Seven interactive scenario tools for payments controllers — covering net revenue, scheme fee accruals, reserve adequacy, FTP float income, issuing net interchange, and ISO revenue share waterfall. Each tool outputs a quantified result, a CFO narrative, and controller talking points. Tools 2–7 auto-run on load with default inputs. Tool 1 (P&A Classifier) opens on question 1.

How to Use These Tools

Enter your actual or estimated inputs and run the scenario. Outputs are directional — they quantify the gap between economic expectations and what lands in the P&L, and give you the language to explain it. These tools are designed to complement the close checklist in Chapter 07 (Reconciliation & Close).

// Seven Questions These Tools Answer

P&A Classifier: For this revenue arrangement, does GAAP support gross or net presentation — and what are the journal entries?

Net Revenue Reality Check: GPV is up — why didn't net revenue follow proportionally?
Scheme Fee Accrual: How many days of Visa/MC fees are unbilled at month-end, and what does that mean for the close?
Reserve Adequacy: Is the current reserve balance adequate under ASC 450, and what is the P&L impact of building or releasing?
FTP Float & Funding Income: Balance × Rate × Days — what is the acquiring float worth at current FTP rates, and what happens if rates or instant settlement mix change?
Issuing Interchange & Rewards: Gross interchange is not what lands — how much does the rewards program consume, and what does the liability look like on the balance sheet?
ISO Revenue Share Waterfall: What does the acquirer actually net after interchange, scheme fees, and ISO revenue share?

// Tool 1 of 7 — ASC 606 Assessment
Principal vs. Agent Classifier

Answer 6 questions about any revenue arrangement — acquiring, platforms, marketplaces, SaaS, embedded finance, lending. The tool applies the ASC 606-10-55-37 control indicators and tells you whether gross or net presentation is supported, with the accounting entries.

Question 1 of 6
skip question
Principal indicators
—
Agent indicators
—
// Accounting entry — your scenario
// Tool 2 of 7
Net Revenue Reality Check

GPV grew — but how much actually lands as net revenue after scheme fees and reserve movement?

// Tool 3 of 7
Scheme Fee Accrual Check

Visa and Mastercard bill in arrears. How many days are unbilled at month-end, and what does that mean for the close?

// Tool 4 of 7
Reserve Adequacy Check

Is the current reserve balance enough? How many days of exposure does it cover, and what needs to be built or released?

// Tool 5 of 7
FTP Float Income Calculator

Balance x Rate x Days. What does the merchant settlement float generate at current FTP rates?

// Tool 6 of 7
Issuing Net Interchange Check

Gross interchange is the headline. How much does the rewards program consume, and what actually lands?

// Tool 7 of 7
ISO Revenue Share Waterfall

What does the acquirer actually net after interchange, scheme fees, and ISO revenue share?

Chapter 17

Fraud Economics
& Accounting

How fraud losses flow through the P&L, how fraud reserves differ from chargeback reserves, and the full accounting framework for network monitoring programs — Visa's VAMP and Mastercard's ECP and EFM — that most controllers learn only when the first assessment arrives.

Fraud and chargebacks are operationally related but financially distinct. A chargeback is a dispute mechanism — the cardholder asserts a claim and the funds reverse through a defined network process. A fraud loss is a direct financial loss incurred when fraudulent transactions settle and cannot be recovered. Controllers who conflate these two expose themselves to misstated reserves, wrong P&L line attribution, and reserve inadequacy surprises.

The Fraud Loss Taxonomy

Acquirer fraud losses fall into three categories, each with different accounting treatment:

Loss TypeHow It ArisesP&L LineReserve?Controller Note
Chargeback-Based Fraud LossFraudulent transaction disputed by cardholder. Chargeback received, merchant cannot/does not fund. Acquirer absorbs net loss.Credit loss / chargeback expenseYes — rolling reserve drawMost common. Same mechanics as any chargeback loss — the fraud label is descriptive, not accounting-determinative.
Non-Chargeback Fraud LossFraudulent transaction settles, no dispute filed. Merchant funded but later identified as fraudulent. Acquirer may bear loss on recovery shortfall.Fraud loss / operating lossSometimes — depends on merchant solvencyRarer but harder to quantify. Often discovered in forensic reviews post-merchant-failure.
Network Compliance FinesMerchant or acquirer breaches network monitoring thresholds. Assessments follow under VAMP (Visa) or ECP / EFM (Mastercard).Scheme fees / compliance finesAccrue when probable — often monthly once a merchant is in a programThe most operationally predictable fraud cost. Often under-accrued because controllers do not monitor merchant-level compliance status.

Network Fraud Monitoring Programs — The Real Cost

Visa and Mastercard operate tiered compliance programs that generate direct financial charges against the acquirer when merchants breach fraud rate thresholds. Understanding these programs is prerequisite to accurate scheme fee accruals.

ProgramNetworkBasisAssessmentAcquirer Liability
VAMP
Visa Acquirer Monitoring Program
VisaCount ratio — TC40 fraud + TC15 disputes ÷ settled CNP transactions (TC05), with defined exclusions. Consolidates the retired VDMP and VFMPPer the current published program materials. Where the acquirer-eligibility condition is met, the excessive-merchant threshold is 150 bps effective 1 April 2026 with a minimum monthly count (AP, Canada, EU, U.S.); acquirer thresholds and other regions differAssessed to the acquirer, not the merchant. Cure or pass through per the MPA
ECP
Excessive Chargeback Program (ECM / HECM)
MastercardCurrent-month chargebacks ÷ prior-month transactions — the period offset mattersPer current Mastercard monitoring and pricing resourcesAssessed to the acquirer. Issuer reimbursement may apply per current rules
EFM
fraud monitoring
MastercardFraud thresholds, assessed independently of ECPPer current Mastercard resourcesA merchant can breach ECP, EFM, or both — test each separately
// Controller Watch-Out — One Merchant Can Breach More Than One Program

A single deteriorating merchant can breach monitoring on more than one axis at once. The structures to model, however, are the current ones: Visa's VAMP (which already consolidates the former dispute and fraud programs into a single count-based ratio) and Mastercard's ECP for chargebacks with EFM for fraud, assessed separately. A merchant processing on both networks can be in VAMP and in ECP and/or EFM simultaneously.

Do not model simultaneous VDMP and VFMP charges. Those were separate Visa programs and no longer operate as such — VAMP replaced both, so stacking two Visa fee streams on one merchant double-counts a program structure that no longer exists. The worked "$35,000 from VDMP alone, over $70,000 combined" figure was built from retired per-dispute and tiered fine tables that are not substantiated as current, and should not be used as an accrual input or a business case.

What to build instead: merchant-level monitoring against each network's current published parameters, with the assessment taken from the applicable current fee schedule rather than a remembered table. Then apply the accrual test below — enrollment alone does not make every forecast future charge a liability.

Fraud Reserve vs. Chargeback Reserve — The Accounting Distinction

These are commonly described as sitting together "under ASC 450." They do not. As set out in Chapter 5, three different records are involved, each with its own standard, and collapsing them is what produces reserve balances no one can reconcile:

One Standard Does Not Cover All Three
Merchant-funded collateral — reserves withheld from settlement — is the merchant's money and a liability from inception (ASC 405-20). It is never a loss accrual, and applying it to a loss does not create expense.
Amounts owed to you by merchants — funded chargebacks, negative balances, fees billed in arrears — are financial assets carrying an expected-credit-loss allowance under ASC 326, measured from origination.
Contingent exposure beyond any recorded asset — disputes not yet filed, program assessments not yet incurred — is where ASC 450-20-25-2 (or ASC 460 in guarantee scope) applies.

Only the third is an ASC 450 contingency. Labelling all three "reserves" and testing them against one standard leaves the CECL allowance unmeasured and treats merchant collateral as though it absorbed the acquirer's own losses.

The estimation methodology also differs by exposure — and the formulas below need their units stated:

Define the Units, and Use Loss Probability Not Win Rate
Do not mix count-based and value-based inputs. "Chargeback rate × average loss × volume" multiplies a count ratio by a dollar average by a dollar amount — dimensionally incoherent. Pick one basis and hold it: for a count model, expected claim count × average disputed ticket × percentage unrecovered; for a value model, disputed dollars ÷ total dollars, applied to volume. Per Chapter 8, a count ratio applied to GTV assumes disputed tickets equal average tickets, which they do not.

Multiply by the probability of losing, not winning. An expected loss uses the share of disputes you expect to lose. Using an expected win rate inverts the estimate — at a 70% win rate, reserving 70% of exposure over-reserves by more than double when the correct figure is the 30% you expect to lose.

Deduplicate the populations. Fraud losses and chargeback losses overlap: most fraud becomes a chargeback. Reserving separately for a fraud exposure and again for the chargeback it later produces counts the same loss twice. Define the fraud reserve as covering the incubation window only — identified fraud not yet disputed — and hand the exposure over to the chargeback reserve once the dispute is filed, with the transfer visible in the roll-forward.
ASC 450-20-25-2; ASC 326-20-30-2; ASC 460-10; ASC 405-20-40-1.
Reserve TypeWhat It CoversEstimation BasisBalance Sheet Line
Chargeback ReserveFuture merchant debit shortfall on chargebacks already received or probableExpected claim count × average disputed ticket × percentage expected unrecovered (not win rate) — see the units note aboveChargeback Reserve Liability
Fraud ReserveEstimated losses from fraudulent transactions not yet disputed — the "incubation period" before chargebacks are filedIdentified fraud not yet disputed, over the incubation window only — hand over to the chargeback reserve once a dispute is filed, to avoid double-countingFraud Loss Reserve or combined with CB reserve with separate disclosure
Compliance Program AccrualAssessments already incurred under VAMP / ECP / EFM — not a forecast of future monitoring chargesCurrent enforceable obligation from the applicable published schedule; see the note belowAccrued Network Compliance Fees (within scheme fee payable)
Enrollment Is Not an Obligation for Every Future Month
"Monthly fee schedule × expected months remaining in program" accrues the entire forecast run of monitoring charges the moment a merchant enrols. That is a budget, not a liability. Most of those future months are avoidable — by remediation, by the merchant exiting the program, or by termination — and a cost you can still avoid is not an obligation you have incurred.

Split the exposure in two:

Accrue what is already incurred. Assessments arising from activity that has occurred — breached months already assessed, per-item charges on disputes already filed — are present obligations and are measured from the applicable current schedule.
Forecast the rest. Expected future monitoring charges, contingent on the merchant remaining in breach, belong in the budget and the remediation business case. Where a future obligation is genuinely probable and estimable — the merchant is committed to the program period with no realistic remediation path — accrue that specific amount and document why it is unavoidable.

This is the same discipline as Chapter 14's catch-all cushion, in the opposite direction: there, a percentage buffer recorded a liability with no identified obligation; here, a forecast schedule records liabilities for months that have not happened. Both fail the same test.
ASC 450-20-25-2 and 25-8. Program parameters: Visa VAMP fact sheet; Mastercard Security Rules and Procedures §8.3.

Journal Entries — Fraud Loss Lifecycle

// F1 — Fraudulent Transaction Settles (before dispute)

Dr. Settlement Receivable          $5,000
  Cr. Merchant Payable                     $5,000
// Normal settlement entry. No fraud impact yet — transaction processes normally.

// F2 — Fraud Reserve Accrual (incubation period)

Dr. Fraud Loss Provision             $420
  Cr. Fraud Loss Reserve                  $420
// Based on historical fraud rate. Recognized before chargebacks are filed. Non-cash accrual.

F3 and F4 Are Alternative Outcomes — Not a Sequence
The two entries below are branches. Exactly one of them happens for any given fraudulent transaction. Run consecutively they release the $420 provision twice and credit the same $5,000 twice, so the ledger is relieved of $10,000 of exposure that only ever existed once.

Also check what is available to net against. If the merchant has already been funded, there is no merchant payable left to debit — the acquirer has paid the money out. The recovery then runs through a merchant receivable and the merchant's own cash, which is precisely the exposure that makes an unrecovered fraud loss possible. An entry that nets a chargeback against a payable which was settled days earlier assumes collateral that is not there.
// F3 — Network debits the chargeback (common to both branches)

Dr.  Merchant Receivable           $5,000
  Cr.  Cash / Settlement Payable     $5,000
// The network takes the money. Record what the merchant now owes you.
// Fraud reserve balance unchanged at $420.

// F3a — BRANCH A: merchant pays (recovered)

Dr.  Cash                              $5,000
  Cr.  Merchant Receivable            $5,000

Dr.  Fraud Loss Reserve              $420
  Cr.  Fraud Loss Provision           $420
// Receivable collected in full. The covered exposure resolved with no loss,
// so the provision is released. Reserve: $420 → $0. Net P&L on the event: nil.

// F4 — BRANCH B: merchant cannot pay (unrecovered)

Dr.  Fraud Loss Reserve              $420
Dr.  Fraud Loss Expense             $4,580
  Cr.  Merchant Receivable            $5,000
// The receivable is written off. The provision absorbs $420; the $4,580
// shortfall hits the P&L. Reserve: $420 → $0. Net P&L on the event: $(4,580).

Reserve Roll-Forward — Both Branches
Branch A — recoveredBranch B — unrecovered
Opening fraud reserve (F2)$420$420
Utilized against loss$0($420)
Released — exposure resolved($420)$0
Closing reserve$0$0
P&L impact of the eventnil$(4,580)
The reserve reaches zero either way, but for different reasons — released in one, consumed in the other. A roll-forward that cannot distinguish utilization from release will not explain the P&L, and is the first thing to build when a fraud reserve stops reconciling.
ASC 326-20-35-8; ASC 450-20-25-2; ASC 210-20-45-1.
// F5 — Network monitoring assessment accrual

Dr.  Scheme Fee Expense — Compliance   [incurred amount]
  Cr.  Accrued Network Fees                [same]
// Accrue assessments actually incurred under VAMP / ECP / EFM, taken from
// the current published schedule — not a forecast of future monitoring months.
// Invoice follows the network billing cycle; true up on receipt.

The 3DS Economics: Fraud Liability Shift and Revenue Impact

3D Secure authentication on CNP transactions shifts fraud chargeback liability from the acquirer to the issuer — for authenticated transactions, the acquirer is not liable for fraud-based chargebacks. The controller implication: 3DS adoption rates directly affect your fraud reserve adequacy model.

// 3DS Impact on Reserve Methodology

The directional point is right: applying a single fraud rate across all CNP volume over-reserves the authenticated segment and under-reserves the unauthenticated one. Net reserves may look adequate while the composition is wrong — which matters the moment a fraud spike lands in the unauthenticated segment.

But "near zero" for authenticated volume is too strong. The reserve should be reduced to reflect verified liability shift, not zeroed against a 3DS flag.

A 3DS Flag Is Not the Same as Liability Having Shifted
Segment by verified liability-shift status, not by whether authentication was attempted. Several things break the equivalence:

Eligibility and exclusions. Liability shift applies to defined transaction types in defined regions. Some categories are carved out entirely, and an authenticated transaction outside the covered set carries the same fraud exposure as an unauthenticated one.
Attempted vs. fully authenticated. The outcome of the authentication matters. An attempt where the issuer did not authenticate, or a frictionless flow that failed, does not necessarily produce the same protection as a completed challenge — and the authentication result must be present and correctly populated in the authorization and clearing data for the protection to hold.
Data integrity through the chain. If the authentication values are not carried correctly into clearing, the transaction can lose its protection even though your gateway recorded a successful 3DS result. This is a reconciliation problem that shows up only at dispute time.
Only fraud dispute conditions shift. Liability shift addresses fraud. An authenticated transaction remains fully exposed to non-fraud disputes — goods not received, not as described, cancelled recurring, processing errors — which in some verticals are the larger share of losses. The networks also provide for disputes to be invalidated or re-presented where authentication applies, so the practical outcome depends on the specific dispute condition rather than the flag.

What to build: tag volume by verified liability-shift outcome rather than by 3DS attempt, hold a reduced but non-zero rate for the shifted segment covering non-fraud dispute types and data-integrity failures, and reconcile the shifted-volume tag against actual dispute outcomes each period. If disputes are landing on volume your model marked protected, the tag is wrong — and that is worth finding before the reserve is.
Visa Core Rules §11.7, including the condition 10.4 invalid-dispute and authentication provisions; Mastercard Transaction Processing Rules (authentication and liability shift); ASC 450-20-25-2; ASC 326-20-30-2.
Chapter 18

Merchant Bankruptcy
& Credit Risk

What actually happens when a merchant fails — the reserve draw-down sequence, loss recognition timing, clawback mechanics, proof-of-claim filing, and the accounting treatment for partial recoveries. The highest-stakes event in acquirer finance, and the one least covered in training.

A merchant bankruptcy is simultaneously a risk event, a legal event, a cash event, and an accounting event — and they do not all happen at the same time. The controller's job is to understand the sequence, account for each stage correctly, and ensure that the financial statements reflect reality before and after the insolvency event with appropriate reserve coverage.

The Merchant Default Timeline

StageTimingAcquirer ActionAccounting Trigger
Early Warning SignsWeeks to months before defaultIncrease reserve, tighten settlement funding, initiate risk monitoringASC 450 — increase reserve when loss becomes probable and estimable
Funding Hold PlacedAt risk event identificationHalt merchant settlement funding. Funds held pending resolution.Settlement receivable remains on balance sheet. No loss yet — funds are held, not lost.
Chargebacks Begin ArrivingT+30 to T+120 from last transactionDraw from reserve. Attempt merchant debit. Represent winnable disputes.Dr. Reserve Liability / Cr. Settlement Receivable (as each CB draws reserve)
Reserve ExhaustedWhen CB volume exceeds reserve balanceAcquirer begins absorbing net losses directlyDraw against the existing allowance first; expense only an incremental shortfall. Relieve the merchant receivable, not the network settlement receivable
Bankruptcy FiledFormal legal proceeding initiatedFile proof of claim in bankruptcy court for net exposureAssess recoverability. Write down receivable to estimated recovery value. May trigger impairment.
Proof-of-Claim FiledCourt-imposed deadline (bar dates vary by case — typically 60–180 days from filing; verify the specific case bar date immediately upon receiving notice of filing)Submit documentation of acquirer's net claimNo new accounting entry — the claim is for an already-impaired asset
Partial RecoveryMonths to years — bankruptcy proceedingsReceive distribution from estateDr. Cash / Dr. Allowance / Cr. Merchant Receivable. Recovery income only where collection exceeds the estimate, or the asset was already fully written off

Reserve Draw-Down Sequence — Journal Entries

First: Whose Money Is the "Reserve" in This Sequence?
The entries below only make sense once that is settled, and the two possibilities book differently from the very first line:

The acquirer's own loss allowance — an estimate of losses the acquirer expects to bear. Established by a charge to expense, drawn down as covered losses occur. That is what B1 below models.
Merchant-funded collateral — money withheld from the merchant's settlement. Established by debiting merchant payable, never by expense, and applied against a recorded merchant obligation rather than absorbing the acquirer's P&L (Chapter 5).

Booking merchant collateral as an expense overstates cost of risk and understates the liability owed to the merchant. Booking an own-loss allowance out of merchant payable does the reverse. Many portfolios carry both — keep them in separate accounts with separate roll-forwards.
// B1 — Allowance build (acquirer's own expected loss)

Dr.  Credit Loss Expense            $500,000
  Cr.  Allowance for Credit Losses   $500,000
// The P&L charge happens HERE, not later. Allowance balance: $500,000.

// B2 — Covered losses draw against the allowance

Dr.  Allowance for Credit Losses   $180,000
  Cr.  Merchant Receivable            $180,000
// Utilization, not expense — the cost was recognized in B1.
// Allowance balance: $500,000 − $180,000 = $320,000 remaining.

// B3 — Further covered losses of $320,000

Dr.  Allowance for Credit Losses   $320,000
  Cr.  Merchant Receivable            $320,000
// Still utilization. No incremental expense — the allowance covers it.
// Allowance balance: $320,000 − $320,000 = $0. Cumulative P&L still $500,000.

The $320,000 That Gets Expensed Twice
The intuitive B3 — Dr Credit Loss Expense $320,000, captioned "reserve exhausted" — charges the P&L a second time for losses the B1 allowance was built to absorb. The allowance was not exhausted: $180,000 of $500,000 had been used, leaving exactly the $320,000 those losses consume. The result is $820,000 of expense on $500,000 of losses, with a $320,000 allowance still sitting on the balance sheet unrelieved.

Expense only the incremental shortfall. If covered losses had reached $560,000, the correct treatment is $500,000 of utilization plus $60,000 of additional expense — reached by re-measuring the allowance against remaining expected losses, not by expensing each new loss as it arrives.

And total the whole event. A summary reading "B3 expense + B4 expense − B5 recovery" omits B1's $500,000 — the largest charge in the sequence and the one that actually hit the P&L. Cumulative event cost is the allowance built plus any incremental shortfall, not the entries that happen to sit nearest the bankruptcy.

Check the obligor on the credit leg. These losses are owed by the merchant, so they relieve a merchant receivable. Crediting the settlement receivable writes down money the network owes you, which no merchant default affects.
ASC 326-20-35-8 (utilization and write-off); ASC 450-20-25-2; ASC 405-20-40-1.
// B4 — Bankruptcy: measure the allowance on the gross claim

Gross claim against the estate: $85,000
Expected collection (illustrative 20%): $17,000
Allowance required: $85,000 − $17,000 = $68,000

Dr.  Credit Loss Expense             $68,000
  Cr.  Allowance for Credit Losses    $68,000
// Expense the UNRECOVERABLE portion, not the gross claim. Writing off the
// full $85,000 while expecting $17,000 back over-reserves by the expected recovery.
// Receivable stays gross at $85,000; allowance $68,000; net carrying value $17,000.

// B5 — Final resolution: distribution received

Dr.  Cash                              $17,000
Dr.  Allowance for Credit Losses    $68,000
  Cr.  Merchant Receivable             $85,000
Dr $85,000 = Cr $85,000 ✓
// No recovery income arises. The outcome matched the estimate, so the
// allowance is simply consumed as the gross receivable is removed.

Recovery Income Only Where the Estimate Was Wrong — or the Asset Was Gone
Crediting $68,000 of "Bad Debt Recovery Income" on a $17,000 cash receipt manufactures income from an allowance that was correctly estimated. Nothing was recovered beyond expectations and no remeasurement occurred — the entry simply relieves a liability account into the P&L.

There are two situations where income genuinely appears, and both look different:

The estimate proved conservative. If $30,000 arrives against a $17,000 expectation, the $13,000 excess reduces credit loss expense (or is recognized as a recovery) — and only that excess.
The receivable was already fully written off. Then no gross asset or allowance remains, and a subsequent receipt is recorded as a recovery when collected, with the allowance reassessed afterwards.

State the opening position explicitly — gross claim, allowance, net carrying value — before any resolution entry. Most errors here come from a journal written without knowing whether the asset is still on the books gross, carried net, or already removed.
ASC 326-20-30-2; 326-20-35-8; 326-20-55-51 through 55-53.

CECL Application to Merchant Receivables (ASC 326)

Under the Current Expected Credit Loss model, the acquirer must estimate lifetime expected credit losses on the settlement receivable portfolio at each reporting date — not just when a specific merchant shows stress. But be precise about which assets are in scope and who owes them.

Identify the Obligor Before Applying a Default Rate
Three assets get treated as one exposure in most acquirer CECL models, and they have different obligors:

Settlement receivable — owed by the network. Applying a merchant default rate to it measures the wrong counterparty entirely. A merchant failing does not impair what the network owes you for transactions already cleared. Assess it against the network's credit, where the expected loss is typically very small and the holding period short.
Merchant receivable — owed by the merchant. Funded chargebacks, negative balances, fees billed in arrears. This is where merchant default experience belongs, and it is the asset a bankruptcy actually impairs.
Rolling reserve — a liability, not an asset. It is merchant money you hold. It has no CECL allowance because it is not a financial asset of yours; it is an obligation to return funds. Listing "rolling reserves" among assets requiring a Day-1 loss estimate inverts the balance sheet.

Holding merchant funding does not leave a network receivable outstanding. Withholding settlement from a merchant affects what you owe them; the network has already settled with you. Conflating the two produces a model where reserve balances appear to increase credit exposure, when they reduce it.

Practical test: for every balance in the CECL model, name who would have to fail for you to lose money. If the answer is "the merchant" but the account is the settlement receivable, the model is measuring the wrong thing. And contingent exposures that are not recognized assets at all — disputes not yet filed, guarantee-type obligations — belong under ASC 450 or ASC 460, not ASC 326.
ASC 326-20-15-2 (scope) and 30-2; ASC 405-20-40-1; ASC 460-10.
// CECL vs. Incurred Loss — The Practical Difference

Under the old incurred loss model (pre-CECL), you recognized a reserve only when a specific loss was probable. Under CECL, you recognize a Day 1 allowance based on the expected loss over the life of the asset — even if no specific merchant is showing stress. The estimate is made at each reporting date on the in-scope assets, using historical experience adjusted for current conditions and reasonable and supportable forecasts.

Clawback Mechanics

A clawback occurs when an acquirer attempts to recover funds already paid to a merchant for transactions that subsequently generated chargebacks. The legal right to claw back is established in the Merchant Processing Agreement — but the practical ability depends entirely on whether the merchant has funds in their DDA or whether a funded reserve is available.

// Controller Talking Point — Reserve vs. DDA Recovery Priority

The intended sequence is: draw the funded reserve, then debit the merchant DDA, then absorb the residual. The balance-sheet mechanics are right — reserve draws reduce the liability, DDA debits create or increase a receivable, and the unrecovered remainder is expense.

But each step is conditional on an enforceable right, not on a contract clause. The MPA granting a right of recovery is where the analysis starts, not where it ends:

Applying the reserve requires that the funds are genuinely available to apply — which depends on how they are held, whether they are restricted, and what rights attach to them.
Setoff against amounts owed is a legal right that must exist and be exercisable, and its availability can change materially once insolvency proceedings begin.
Debiting the merchant's DDA assumes both that funds are there and that the debit is permitted. After a filing, unilateral collection steps against the debtor may be constrained regardless of what the MPA says, and an ACH debit that is authorized contractually is not therefore collectible or permissible.

Accounting consequence: reflect only recoveries that are legally available, identify the obligor for each one, and confirm any balance-sheet offset meets the right-of-setoff conditions rather than assuming it. Model the waterfall as conditional, with legal clearance as a gate on the first two steps — and get case-specific advice once a filing occurs. The entries above are the accounting; enforcement is a legal question the accounting depends on.

Chapter 19

Deferred Revenue
& Contract Liabilities

When payments revenue must be deferred under ASC 606 — setup fees, annual fees, SaaS-bundled payment arrangements, hardware amortization, and the roll-forward mechanics that belong in every payments controller's close package.

In traditional card acquiring, revenue recognition was straightforward: MDR at clearing, done. Modern integrated payments — software-led, subscription-bundled, hardware-embedded — creates multiple performance obligations in a single merchant contract. Getting this wrong creates restatement risk, not just a timing difference — and the first thing to get right is why a liability arises at all.

Over-Time Recognition Does Not Create a Contract Liability — Advance Payment Does
"When obligations are satisfied over time rather than at a point, revenue must be deferred" conflates two independent things. The recognition pattern and the existence of a liability answer different questions:

A contract liability arises when consideration is received, or is unconditionally due, before the entity performs. That is what "deferred revenue" describes. It can arise on a point-in-time obligation just as easily — a fee collected in advance of a single future service is a contract liability.
An over-time obligation billed in arrears creates the opposite. Performance precedes payment, so it produces a receivable (if the right to consideration is unconditional) or a contract asset (if conditional on something more than the passage of time). Nothing is deferred at all.

So the test is timing of payment against performance, not whether recognition is ratable. A monthly SaaS fee billed monthly in arrears and recognized over the month generates no deferred revenue; the same fee billed annually up front generates a substantial one.

Keep lease components out of this. Where terminal rental is a lease, the lessor accounting — including any deferred lease income — sits under ASC 842, not in the ASC 606 contract liability. Folding lease revenue into the deferred revenue roll-forward mixes two standards in one account and breaks both the revenue disaggregation disclosure and the lease disclosures.
ASC 606-10-45-1 through 45-4 (contract assets, liabilities and receivables); ASC 606-10-15-2(a); ASC 842-30 (lessor).

Common Deferred Revenue Triggers in Payments

Revenue TypeDeferred?Recognition PatternCommon Mistake
Setup / Onboarding FeeYes — if the setup does not transfer a distinct service to the merchantStraight-line over expected customer life or initial contract termRecognizing the full setup fee in month 1 as the "work is done." If the setup is not a distinct performance obligation, it must be deferred and recognized over the contract.
Annual Platform / SaaS FeeYes — recognized ratably over the period covered1/12 per month over the annual contract termBooking the full annual fee as revenue in the month it is invoiced or received.
Bundled SaaS + ProcessingPartially — SaaS component deferred; processing recognized at clearingAllocate transaction price between distinct obligations using SSP (standalone selling price)Recognizing 100% of a bundled fee as processing revenue when a portion is attributable to software access or other services.
Hardware (Terminal) SaleNo — point-in-time recognition at deliveryRevenue recognized when control transfersTreating terminal sales like leases. If the merchant owns the terminal after purchase, it is a sale, not a lease. ASC 842 does not apply.
Hardware (Terminal) LeaseYes — lease payments recognized over lease term (ASC 842)Interest income (finance lease) or ratable (operating lease)Capitalizing all lease payments immediately. POS terminal leases require ASC 842 classification and the applicable income recognition pattern.
Volume Rebate / IncentiveDepends — may require constraint under variable consideration rulesInclude in the transaction price only to the extent it is probable that a significant revenue reversal will not occur (ASC 606-10-32-11) — the U.S. GAAP constraint, not IFRS's "highly probable"Front-loading annual volume incentives in Q1 before it is probable the thresholds are met. ASC 606 requires constraint until this test is passed.

The Standalone Selling Price (SSP) Problem

When a merchant contract bundles multiple services — processing, software, hardware, support — the transaction price must be allocated to each distinct performance obligation based on its standalone selling price. If the company does not sell each component separately, SSP must be estimated using the adjusted market assessment approach, expected cost plus margin, or residual approach.

// Example — Bundled Contract Allocation

A merchant signs a 2-year contract: $150/month total. Includes payment processing (SSP: $120/month), software POS access (SSP: $40/month), and 24/7 support (SSP: $15/month). Total SSP = $175/month. Allocation ratios: processing 68.6%, software 22.9%, support 8.6%.

Monthly allocation at the $150 contract price: Processing $102.86, Software $34.29, Support $12.85 — summing to exactly $150.00.

Watch the rounding. Rounding each component independently gives $102.86 + $34.29 + $12.86 = $150.01, a penny above the contract price. Trivial on one merchant; across a portfolio booked monthly it becomes a recurring unexplained difference between allocated revenue and billed consideration. Adopt a stated convention — allocate the residual to one designated component — and apply it consistently.

Define what each component's recognition follows. "Recognized at each clearing" describes how the processing fee is billed. A fixed monthly amount for a stand-ready processing obligation is generally satisfied over the service period rather than transaction by transaction. Identify the promised service before choosing the pattern — a fixed availability commitment and a per-transaction service recognize differently even when the merchant pays one bundled price.

Do not reallocate when a price later changes. SSPs are established at contract inception. A subsequent pricing change is assessed as a contract modification under ASC 606-10-25-10 through 25-13 — which may be a separate contract, a prospective change, or a cumulative catch-up depending on the facts. Routinely refreshing SSPs and reallocating the original transaction price is not the model, and it produces revenue movements no one can trace to a contract event.

Deferred Revenue Roll-Forward — The Close Procedure

// D1 — Setup Fee Received, Deferred

Dr. Cash / Accounts Receivable        $2,400
  Cr. Deferred Revenue (Contract Liability)  $2,400
// $2,400 setup fee for a new merchant. No distinct performance obligation at onboarding — must be deferred over 24-month expected customer life = $100/month recognition.

// D2 — Monthly Revenue Recognition from Deferred Balance

Dr. Deferred Revenue (Contract Liability)  $100
  Cr. Revenue — Setup Fee Amortization    $100
// Monthly release. Run as a systematic schedule — not a journal judgment. The entire deferred revenue balance should tie to an amortization schedule by contract/cohort.

// D3 — Early Merchant Termination (accelerated recognition)

Dr. Deferred Revenue (Contract Liability)  $1,600
  Cr. Revenue — Setup Fee Amortization    $1,600
// Merchant terminates at month 8 with $1,600 of deferred balance remaining.
// Acceleration is correct ONLY where the conditions below are met — verify first.

Termination Does Not Automatically Release the Balance
Recognizing the remaining $1,600 "because the performance obligation period is over" assumes the obligation was extinguished and the consideration was earned. Termination establishes neither on its own. Work through four questions before accelerating:

Is any of it refundable? If the merchant is contractually entitled to a refund of the unearned portion, the balance is a refund liability, not revenue. Check the termination clause, not the amortization schedule.
Does anything survive termination? Post-termination obligations are common in payments — chargeback handling on prior transactions, data access and export, run-off support. If the entity must still perform, the related consideration stays deferred.
Was the fee for what you assumed? A setup fee deferred over a 24-month "expected customer life" is often compensating an upfront activity plus a material right to continue at renewal. What the fee actually benefited determines what happens when the relationship ends.
Is the entity entitled to keep it? Acceleration requires entitlement to the consideration, which usually turns on an early-termination provision. Without one, retaining the cash may not be supportable.

Where a material right lapses unexercised, recognition follows the breakage guidance rather than a blanket release at termination. And where the merchant simply stops processing without formally terminating, nothing has necessarily changed contractually at all.

The correct entry may be acceleration, may be a refund liability, or may be no entry yet. Document which and why — this is precisely the population an auditor samples when deferred revenue releases spike in a quarter.
ASC 606-10-55-50 through 55-53 (customer options, breakage); ASC 606-10-25-1 through 25-8; ASC 405-20-40-1 (extinguishment).

Deferred Revenue Balance Sheet Management

The deferred revenue liability should be split between current (recognized within 12 months) and non-current on the balance sheet. As the merchant portfolio grows, the deferred revenue balance grows with it.

But growing deferred revenue is not a funding problem — it is usually the opposite. The cash arrived before the service was delivered, so prepayments supply operating cash. A business with a growing deferred revenue balance is being financed by its customers. Saying the liability "creates working capital pressure even though the cash has already been received" treats a cash inflow as a cash strain.

Three distinct things get merged under that phrase, and they should be stated separately:

Cash effect — positive. Prepayments increase cash now against performance later.
Reported ratios — mechanically worse. A current liability rises with no corresponding current asset once the cash is spent, so the current ratio falls. That is a measurement artifact of the ratio, not a liquidity event, and it is worth explaining to anyone reading the balance sheet without context.
Future cost — real but separate. The obligation to deliver services carries a future cost that the cash received must ultimately cover. That is a margin and capacity question, not a working capital one.

Say which of the three you mean. This genuinely is the mirror image of the settlement receivable dynamic — there, revenue is recognized before cash arrives; here, cash arrives before revenue is recognized — and controllers should present both together.

// Monthly Close Checklist — Deferred Revenue
  • Roll forward the deferred revenue schedule: opening balance + new deferrals - recognized = closing balance
  • Tie closing balance to the GL deferred revenue account — investigate any variance
  • Identify early terminations in the period and accelerate recognition as appropriate
  • Split balance between current (next 12 months' amortization) and non-current
  • For bundled contracts, confirm SSP allocation has not changed — MDA pricing changes require SSP refresh
  • Disclose significant judgments (customer life assumptions, SSP methodology) in the accounting policy footnote
Chapter 20

Stablecoins &
Crypto Payment Acceptance

The controller's framework for digital asset payment acceptance — ASC 350 vs. fair value accounting, stablecoin settlement mechanics, crypto-to-fiat conversion timing, and the emerging regulatory and accounting standard landscape for 2024–2026.

Crypto payment acceptance is no longer theoretical. Major acquirers and payment platforms now process USDC, USDT, and other stablecoins alongside card rails. For controllers, the accounting questions are not theoretical either. And contrary to a widely repeated claim, there is now definitive guidance for qualifying holdings: ASC 350-60, added by ASU 2023-08, requires fair value measurement with changes in net income. The cost-less-impairment model it replaced is no longer current GAAP for in-scope assets. This chapter covers the current framework, its scope boundaries, and what still falls outside it.

The Three Models of Crypto Payment Acceptance

ModelHow It WorksCrypto Holding PeriodFX/Price ExposurePrimary Accounting Issue
Instant ConvertCrypto received from consumer, immediately converted to fiat by a processor (Coinbase Commerce, BitPay). Merchant receives USD.Seconds — processor bears riskProcessor bears it; acquirer/merchant sees noneRevenue recognition: at what price? FX rate at conversion? At authorization?
Hold & ConvertCrypto received and held on balance sheet. Converted to fiat periodically (daily, weekly).Hours to daysMerchant/acquirer bears volatility during holding periodASC 350 intangible asset treatment vs. fair value — the holding period creates mark-to-market or impairment risk
Stablecoin SettlementConsumer pays in USDC/USDT. Merchant receives stablecoin and either holds or converts. Settlement rails bypass card networks.Varies — some hold stablecoins as treasuryDe minimis for asset-backed stablecoins (USDC, USDT) in normal conditions; material for algorithmic stablecoins — the TerraUSD/UST collapse in 2022 wiped $40B+ in value and demonstrated that algorithmic peg mechanisms can fail catastrophicallyIs a stablecoin a cash equivalent? An intangible? A financial instrument? GAAP currently says intangible asset under ASC 350.

Current GAAP Treatment — ASC 350 Intangible Asset Model

Under current US GAAP (before the FASB's December 2023 ASU 2023-08), crypto assets are classified as indefinite-lived intangible assets under ASC 350. This creates a severely conservative accounting model:

// The ASC 350 Impairment Problem

Under the old model: if you receive Bitcoin at $45,000 and it drops to $40,000 at any point during the period, you must record a $5,000 impairment loss. If it subsequently rises to $50,000, you cannot reverse the impairment — the gain is only recognized on eventual sale. You can record a loss but not a gain. This made crypto holding on corporate balance sheets highly unfavorable from a reported earnings perspective.

ASU 2023-08 — Fair Value Accounting (Effective 2025)

The FASB issued ASU 2023-08 in December 2023, effective for fiscal years beginning after December 15, 2024 (i.e., January 1, 2025 for calendar-year companies). This standard requires fair value measurement for in-scope crypto assets with changes recognized in net income each period.

FeatureBefore ASU 2023-08After ASU 2023-08 (2025+)
Measurement basisHistorical cost less impairment (ASC 350)Fair value at each reporting date
Unrealized gainsNot recognized until saleRecognized in net income each period
ImpairmentRequired when fair value drops below costNot applicable — ongoing fair value measurement replaces impairment model
Balance sheetIntangible asset (net of impairment)Crypto asset at fair value (separate line or within current assets)
Income statement volatilityAsymmetric — losses onlySymmetric — both gains and losses flow through income
ScopeApplied broadly to crypto pre-adoptionOnly assets meeting all six ASC 350-60-15-1 criteria — see below. Active trading is not one of them.
The Six Scope Criteria — and the One That Is Not There
A crypto asset is in ASC 350-60 scope only if it meets all of these:

1. Meets the definition of an intangible asset.
2. Does not provide the holder with enforceable rights to, or claims on, underlying goods, services or other assets.
3. Is created or resides on a distributed ledger based on blockchain or similar technology.
4. Is secured through cryptography.
5. Is fungible.
6. Is not created or issued by the reporting entity or its related parties.

"Traded on an active market" is not among them. Adding it excludes assets that are in scope and suggests a liquidity threshold the standard does not impose — fair value measurement under ASC 820 handles thin markets through the hierarchy, not through a scope exclusion.

Criterion 2 is the one that matters most in payments. A token giving the holder an enforceable redemption right against the issuer, or a claim on reserve assets, fails it and is outside ASC 350-60. That is exactly the design of many fiat-backed stablecoins — so the token most common in payment acceptance is the one least likely to qualify. Criterion 6 also bites for any entity issuing its own token.

Mark pre-adoption material as historical. The cost-less-impairment model with its asymmetric, losses-only pattern is not an alternative policy and not "current GAAP" — it is what applied before adoption. Present it for context only, clearly dated, and check the effective-date and transition provisions for your reporting period.
ASC 350-60-15-1 (scope), 35-1 (fair value measurement), 65-1 (transition); FASB ASU 2023-08.

Stablecoin-Specific Accounting Questions

Stablecoins — USDC, USDT, BUSD, and their successors — introduce specific questions that volatile crypto does not. A stablecoin is designed to maintain a 1:1 peg to USD. Does that make it cash? A cash equivalent? A financial instrument? None of those is answered by the peg — and none is settled by defaulting every token to ASC 350-60.

// Stablecoin Classification Decision Tree

Is it USD? No — it is a digital token on a blockchain. Even if 1:1 pegged, it is not legal tender.
Is it a cash equivalent (ASC 230)? Likely no — it does not mature within 3 months of a fixed amount of cash, and redemption is subject to the stablecoin issuer's operations.
Is it a financial instrument (ASC 825)? Possibly — subject to accounting policy election and technical analysis of the specific token structure.
There is no default. Test the specific token against the ASC 350-60 scope criteria and against the definitions for cash equivalents and financial assets. Different stablecoins reach different answers, and the answer is not a policy election.

Revenue Recognition — Crypto Payment Acceptance

// C1 — Merchant Accepts USDC, Instant Convert to USD

At payment acceptance:
Dr. Settlement Receivable (USD)       $1,000
  Cr. Revenue                              $1,000
// Whose revenue is this — the merchant's sale or the processor's fee? And was the
// contractual right to crypto or to fiat? See the note below before using this entry.

// C2 — Holding a crypto asset through period-end

Receipt of USDC:
Dr. Crypto Asset (USDC)               $10,000
  Cr. Revenue                              $10,000

Period-end fair value adjustment (USDC de-pegs to $0.997):
Dr. Unrealized Loss — Crypto           $30
  Cr. Crypto Asset (USDC)                  $30
// This pattern applies to an asset established as IN SCOPE of ASC 350-60.
// A fiat-backed stablecoin carrying enforceable redemption rights generally is not —
// see the note below. Bitcoin, or a token documented as in scope, is the safe example here.
// De-pegging events are real regardless: USDC briefly de-pegged in March 2023.

Do Not Use a Fiat-Backed Stablecoin as the Fair-Value Example
Declaring stablecoins intangible assets and then placing USDC in ASC 350-60 skips the scope test that decides the answer. A token whose holder has an enforceable claim on the issuer or on reserve assets fails criterion 2 and is outside ASC 350-60 — which is the design of most fiat-backed stablecoins used in payments.

Where it lands instead depends on the token's actual terms, and there are several possible answers: a receivable or other financial asset if the redemption right is enforceable against the issuer; potentially a cash equivalent if it meets the ASC 230-10-20 conditions on its own terms; or, for tokens without such rights, ASC 350-60. The peg is not the test — neither a 1:1 target nor any legal-tender characterization determines classification, and a token can hold its peg perfectly while being a financial asset rather than an intangible. Where the arrangement contains embedded features, ASC 815-15 may also apply.

This is not a policy election. Two entities holding the same token should reach the same conclusion; two different tokens may correctly reach different ones. Read the issuer's terms — what the holder is actually entitled to, from whom, and on what conditions — and document the scope conclusion per token before any measurement follows.
ASC 350-60-15-1(b); ASC 230-10-20 (cash equivalents); ASC 825-10-20; ASC 815-15 where applicable.
"Revenue at USD Equivalent at Conversion" Skips Two Questions
1 · Whose revenue is being recorded? A merchant's $1,000 sale and a processor's fee on that sale are different amounts in different entities' books. An entry crediting Revenue $1,000 is the merchant's; the processor's revenue is its fee, and the $1,000 is money owed onward — the same gross-versus-net question as Chapter 12's PFaaS analysis.

2 · What was the contractual right — crypto or fiat? This decides whether any crypto asset existed at all:

If the customer's consideration is the crypto itself, this is noncash consideration. It is measured at fair value at contract inception, and revenue is recognized when the performance obligation is satisfied — which need not be the conversion moment. Any movement between inception and conversion is a separate gain or loss on the asset, not a change in revenue.
If the contractual right is to a fiat amount, with a processor converting on your behalf, the entity may never have controlled crypto. Revenue is the fiat entitlement and the conversion is settlement mechanics.

Speed is not the test. "Instantaneous conversion means no asset was ever controlled" confuses duration with control — an asset controlled for seconds was still controlled, and that determines recognition and any subsequent measurement. Conversely, an entity that never had a right to the crypto did not control it however long the conversion took. Establish control from the contract, then let the holding period affect only how much measurement follows.
ASC 606-10-32-21 through 32-24 (noncash consideration); ASC 606-10-25-23; ASC 350-60-05-2; FASB ASU 2016-12.

The Controller's Checklist for Crypto/Stablecoin Acceptance

// Looking Ahead — FASB and Regulatory Pipeline

The FIT21 Act (passed House 2024) and ongoing SEC/CFTC jurisdictional clarification will eventually produce clearer accounting and regulatory frameworks. The FASB's crypto standard project is ongoing beyond ASU 2023-08. Controllers in payments should track FASB project updates and IASB activity on digital assets — this space is moving faster than standard-setters can write standards, and the accounting policy you elect today may need to change.

Chapter 21

Escheatment
101

Unclaimed property law applied to payments — which balances escheatable, dormancy period rules by state, remittance mechanics, and the accounting treatment for escheatment liabilities. One of the least-understood compliance obligations in payments finance, and one of the most aggressively audited by state governments.

Escheatment — the legal process by which unclaimed property is transferred to the state after a defined dormancy period — is not optional, not voluntary, and not widely understood in payments finance. States have become increasingly aggressive in auditing financial services companies for unclaimed payment-related balances. The fines and interest on late or missed escheatment filings routinely exceed the underlying unclaimed amounts.

What Is Escheat in Payments?

In a payments context, escheatable property includes any financial obligation to a third party (typically a merchant, cardholder, or former employee) where the holder — the acquirer, issuer, or processor — has lost contact with the owner and cannot remit the funds. The balance does not disappear; it becomes a state government liability after the dormancy period expires.

Property TypeWho Is OwedTypical Dormancy PeriodPayments Example
Uncashed ChecksMerchant, vendor, former employee3–5 years (varies by state)Settlement check mailed to merchant that was never cashed. Outstanding check payable on GL for years.
Unclaimed Credit BalancesMerchant3–5 yearsOver-collection of fees, duplicate charges, or reserve overfunding that was never returned to the merchant.
Unused Gift Card BalancesCardholder3–5 years (many states exempt gift cards with disclosures)Stored-value card balances that were never redeemed. Breakage revenue treatment intersects with escheatment.
Unredeemed Rewards PointsCardholderGenerally 5 years; varies significantlyReward points or cash-back balances that have not been claimed. State treatment highly variable.
Security DepositsMerchant3–5 yearsReserve funds held beyond the contractual release period with no merchant contact.
Payroll / CommissionEmployee / agent1–3 yearsISO residual payments returned as undeliverable. Unpaid commission checks.

The Dormancy Period and Due Diligence Requirements

Every Period in This Chapter Is Illustrative — Verify Against the Statute
Dormancy periods, due diligence windows, notice requirements, reporting deadlines and filing formats are set by state statute, and they differ by state and by property type. A three-year dormancy with a 24-month or similar due-diligence window is a common shape, not a rule — and no accounting standard or network rulebook establishes any of it.

Two specific cautions for payments portfolios:

Property type changes the answer within the same state. Uncashed merchant settlement checks, unclaimed merchant reserve balances, gift card balances, and payroll-related items can each carry different periods and different exemptions.
Jurisdiction is determined by rules you do not choose. Priority generally runs to the owner's last known address, and failing that to the holder's state of incorporation — so a national portfolio files across many states, each on its own schedule.

Control: maintain a dated matrix of applicable periods and requirements by state and property type, sourced to the governing statute and refreshed as legislation changes, and obtain legal advice before relying on any timeline in a filing. Treat the schedule below as a worked shape for understanding the mechanics, never as a compliance calendar.
No ASC or card-network source establishes state dormancy periods; the applicable state statute governs. Accounting for the liability itself: ASC 405-20-40-1.

Before property can be remitted to the state, the holder must complete a due diligence process — typically sending written notice to the last known address of the owner within a specified window before the dormancy period expires. If the owner does not respond, the property is then reported and remitted to the state.

// Dormancy Timeline — Illustrative 3-Year Property

Year 0: Last transaction or owner activity. Dormancy clock starts.
Year 2 to Year 3: Due diligence window. Holder must mail notice to owner's last known address. Some states require a second notice.
Year 3: Dormancy period expires. Property is now legally required to be reported and remitted to the state in the next annual filing.
Annual Filing: Most states require filing between March 1 and November 1. Filing date, format, and remittance method vary by state.

Priority Rules — Which State Receives the Funds?

The U.S. Supreme Court established a two-priority rule for unclaimed property:

For payments companies with national merchant portfolios, this means filing in potentially 50+ states annually — each with slightly different dormancy periods, due diligence requirements, and filing formats.

Accounting Treatment for Escheatment Liabilities

// E1 — Unclaimed Balance Identified (dormancy clock running, pre-escheat)

No reclassification required during dormancy period.
Balance remains in its original liability account (Merchant Payable, Reserve Liability, etc.).
// Tag the specific items internally as dormant/unclaimed for tracking. Do not reclassify until the escheatment threshold is met.

// E2 — Reclassify to Escheatment Liability (at dormancy expiration)

Dr. Merchant Payable (or Reserve Liability)       $12,400
  Cr. Unclaimed Property Liability — Escheatable   $12,400
// Reclassify to a dedicated unclaimed property liability account when dormancy expires. This separates pending escheatment obligations from active operating liabilities for reporting purposes.

// E3 — Remittance to State

Dr. Unclaimed Property Liability — Escheatable    $12,400
  Cr. Cash                                             $12,400
// Cash remitted to the state. The liability is extinguished — remittance is not an
// expense, because a liability already existed. Note this does NOT imply an earlier
// P&L charge: withholding merchant settlement or holding merchant funds creates a
// liability with no expense at inception. Only balances that previously ran through
// income (e.g. eligible breakage recognized as revenue) had any P&L history at all.

// E4 — Owner Claims Property After Remittance to State

No entry on your books — once remitted to the state, the owner claims directly from the state. The holder (you) is discharged from the obligation upon valid remittance.
// The state maintains the unclaimed property registry and pays claims from owners who come forward. Your obligation is extinguished upon remittance.

The Breakage Revenue Intersection

Gift cards and reward points require careful analysis at the intersection of ASC 606 breakage revenue and state escheatment law. Under ASC 606, an entity recognizes breakage proportionally as redemptions occur, where it is probable that a significant revenue reversal will not occur. But the standard contains an explicit carve-out that resolves the supposed conflict: consideration the entity is required to remit to another party — including under unclaimed property laws — is excluded from breakage revenue entirely.

// The "Double Exposure" Is Not an Acceptable Position

The scenario usually told: recognize $500,000 of breakage in Year 3; discover in Year 5 that the same balances are escheatable; book an escheatment reserve against revenue already taken. That is described as an unavoidable double exposure. It is not — it is a measurement error made two years earlier.

Where balances are subject to remittance under applicable unclaimed property law, that portion was never eligible for breakage revenue. The correct treatment is to retain the liability for the remittable amount and recognize breakage only on the genuinely eligible remainder. Recognizing revenue and then setting up a compensating "escheatment reserve" for the same balance books income the entity was never entitled to, then offsets it with a provision — two wrong entries whose net effect only looks right.

What the $500,000 example should do instead: split the population before recognizing anything. Determine, by property type and applicable jurisdiction, which balances are remittable and which are not — the answer varies, and some jurisdictions exempt certain instruments. Recognize breakage on the eligible portion; carry the rest as a liability until it is remitted or the obligation otherwise ends. The escheatment cash outflow then extinguishes a liability that was always there, with no P&L surprise in Year 5.

ASC 606-10-55-49 (breakage; amounts remittable to others excluded); ASC 405-20-40-1.

State Audit Risk — What Controllers Must Know

State unclaimed property audits are conducted by third-party contingent fee auditors who earn a percentage of the amounts they identify. This creates aggressive audit behavior. Common audit targets in payments companies:

// Controller Action Items — Escheatment Program
  • Establish a formal unclaimed property tracking process — every liability account should be reviewed for dormant items annually
  • Set up a dedicated Unclaimed Property Liability GL account distinct from operating payables
  • Implement due diligence mailing procedures at the 24-month mark for all escheatable property types
  • File annually in all required states — use unclaimed property compliance software (Sovos, Kelmar, Deloitte UP) for multi-state portfolios. The 2016 Uniform Unclaimed Property Act (UUPA) is the model statute that most states now base their laws on — it is the primary reference document for understanding dormancy periods, due diligence requirements, and holder obligations across jurisdictions
  • Maintain a breakage-escheat bridge: all breakage revenue recognized should be tracked against state dormancy expiry dates
  • Consult with unclaimed property counsel before entering a voluntary disclosure program (VDA) — VDAs can limit lookback periods and penalty exposure significantly
tap anywhere to close  ·  pinch to zoom