Reconcile Merchant Card Deposits to Bank at Month-End

Reconcile merchant deposits to bank month-end means tying the gross sales each card processor reports on its monthly statement to the net amount that actually hit your operating account, after fees, refunds, chargebacks, and any rolling reserve. Visa and Mastercard typically settle in T+1 to T+2 business days. American Express settles anywhere from 1 to 7 business days depending on the contract — some legacy direct contracts still batch weekly. Discover varies, usually T+2 to T+3. The reconciliation closes when each processor's expected deposit, calculated as gross sales minus fees, refunds, chargebacks, and reserve, matches the bank deposit on its funded date. Batches that close in the last days of one month but fund in the first days of the next get carried as a timing variance, not chased as an error.

Half of what currently ranks for "credit card reconciliation" answers a different question: cardholder spend reconciliation, where an employee's card receipts are matched back to the credit card statement. That is not this. This is the merchant-acquirer side — your processor settled $X to your bank and your bank shows $Y, and you have to explain the difference before you can close the books. The reconciliation is mostly arithmetic and timing once you have the right rows in front of you, and the procedure is repeatable across processors. The hard parts are knowing which fee-shape your contract uses, recognizing a cross-month batch when you see one, and tracing a chargeback that reduced a deposit without ever showing up as its own bank line.

The scale of what is moving through this workflow is genuinely large. U.S. general-purpose card payments reached 153.3 billion transactions and $9.76 trillion in value in calendar year 2022, the most recent year covered by the Federal Reserve Payments Study. For a multi-channel merchant running Stripe online, a traditional acquirer at the in-person terminal, and a third channel for one-off events, those flows hit the operating account in three or four distinguishable streams every business day, each on its own settlement cycle, each with its own fee shape, each carrying its own chargeback and reserve rules. Tying them out at month-end is a load-bearing close-cycle job that decides whether sales, fee expense, and chargeback expense are right on the income statement.

The rest of this piece is the workflow. Gross-versus-net arithmetic and the two contract shapes — fees deducted at deposit on Stripe and Square, fees billed monthly on some traditional acquirer contracts — anchor everything that follows. The settlement-timing chart for Visa, Mastercard, Amex, and Discover sits next to the cross-month batch logic. There is a copyable spreadsheet schema with named columns, a six-cause variance-reason decision tree for stuck reconciliations, the multi-processor split when one operating account holds many MIDs, an honest read on what bank feeds and accounting software actually reach, and a documentation pattern for the close file. None of it requires a reconciliation product; it does require getting the per-batch detail off your merchant statements and into rows, which is the same extraction-and-exception bottleneck the broader payment reconciliation process and exception patterns treats more generally.

The gross-vs-net mental model and the two fee-shape variants

The arithmetic that anchors every merchant-deposit reconciliation is one equation, applied per batch:

Gross sales − refunds − chargebacks − processor fees − rolling reserve = expected bank deposit.

Each subtraction is a line on the merchant statement, and each appears differently — sometimes as its own bank entry, sometimes folded silently into the deposit, sometimes invoiced separately at month-end. Knowing which subtraction shows up where on your contract is what makes the reconciliation tractable.

There are two fee-shape variants in the wild, and which one your processor uses changes the equation you actually run.

Fees deducted at deposit. Stripe, Square, PayPal, and most modern PSPs subtract fees inside the payout itself. The bank deposit you see is already net of fees, so the equation reads gross minus fees minus refunds minus chargebacks (and minus any rolling reserve where the contract carries one). Reconciling here means matching each daily payout (or rolling-balance payout) to the bank line of the same amount on the funded date. This is the search "Stripe payouts don't match bank deposit" — and the mismatch, when it happens, is almost always one of three things: a chargeback or refund hit after the payout was calculated and rolled into the next day's payout instead, the payout cycle crossed a month boundary, or instant-payout fees were deducted on top of standard processing fees and weren't accounted for. None of these are errors; all of them need to be recognised for what they are.

Fees billed monthly. Some traditional acquirer contracts — certain Worldpay, Heartland, and Elavon arrangements, often described as gross settlement or daily-discount-bypass — deposit the gross daily batch (or close to gross, depending on whether interchange and assessments are netted) and bill processor fees as a single debit at month-end. The equation for the daily lines reads gross minus refunds minus chargebacks (minus rolling reserve where applicable), with no fee subtraction. A separate fees-billed-once entry handles the month's fees on its own line. Reconciliation here has two pieces — daily deposit ties for the operational flow, plus the monthly fee debit — and a practitioner who forgets the second piece will end the month off by exactly the fee total, with every daily line tied. The variance is the fees, sitting in a separate ACH debit nobody added to the schedule.

The implication is that you need to know which model applies to each MID before reconciling, not after. The shape lives in the merchant agreement and on the statement. A daily-settlement statement that prints the day's discount rate and fee per batch is the deducted-at-deposit model; a statement showing daily gross batches funded and a separate page itemizing monthly assessments and interchange is the gross-deposit model. Hybrids are common — interchange-plus contracts where interchange is netted daily but assessments and the processor's markup are billed monthly — and they are the most reliable source of "I thought I knew which one this was." When in doubt, pull the prior month's bank lines for that MID and look for either a monthly fee debit (gross model) or daily payouts that already net to less than the merchant statement's gross sales (deducted-at-deposit model).

Refunds sit inside this same arithmetic and need to land in the right place. On deducted-at-deposit contracts, a refund typically reduces the day's payout — a $200 refund processed on Tuesday makes Tuesday's payout $200 smaller than it would otherwise have been. On gross-deposit contracts the refund either reduces the same day's gross batch or arrives as a separate negative batch to the bank. Either way, the reconciliation should capture refunds in the Refunds column on the matching batch row at the moment of extraction, not as orphan adjustments hunted down later when the variance won't close.

Card-brand settlement timing and the cross-month batch problem

A surprising share of "my close doesn't tie" stories are settlement-timing artifacts rather than reconciliation errors. The merchant statement reports activity on a calendar-month boundary; the bank funds on a settlement-cycle boundary; the two boundaries don't align, and at month-end the gap shows up as missing or extra deposits.

Each card brand publishes its own funding cadence. The numbers below are network-side cycles for typical merchant-direct or processor-direct contracts; actual deposit timing in your bank also depends on the acquirer's funding policy and your bank's cutoff times.

Card brand	Typical settlement cycle	Notes
Visa	T+1 to T+2 business days	Some processor-aggregator contracts add a day.
Mastercard	T+1 to T+2 business days	Same aggregator caveat as Visa.
American Express	1 to 7 business days	OptBlue and direct-merchant contracts sit on the faster end; some legacy direct contracts batch weekly.
Discover	T+2 to T+3 business days	Direct-acquirer contracts typically T+2.

This is where Amex deposit timing reconciliation diverges from the others. A retailer on a weekly Amex batch will see an Amex sales week that closes on Sunday and funds the following Friday — five calendar days later — and at month-end that gap routinely crosses the calendar boundary. A March 30 Amex batch close on a Monday might fund April 4 on a Friday. The merchant statement for March includes the sales; the March bank statement does not include the deposit. The April bank statement carries the deposit; the April merchant statement does not carry the matching sales. Both sides of the reconciliation are right; the calendar is what's misaligned.

The close treatment for cross-month batches is straightforward and worth doing with discipline. Record the unfunded batch as a deposit-in-transit (or sales-receipts-in-transit, depending on your chart of accounts) on the close-month balance sheet, debit the in-transit account, credit accounts receivable or sales clearing, and clear the line the following month when the bank deposit lands by debiting cash and crediting the in-transit account. Flag the batch in the reconciliation file with a timing-variance reason code so the next reviewer can see at a glance why a March batch is sitting in April's bank statement.

A second timing artifact catches readers in close-heavy months: holiday and weekend batching. A Friday T+1 batch funds Monday in normal weeks, Tuesday after a Monday holiday, Wednesday after a two-day federal holiday block. Quarter-end and year-end frequently land near a holiday — the December 31 close after Christmas is the canonical example, where a December 30 batch can fund as late as January 4 depending on the calendar — and the misalignment compounds across processors that share the holiday. A merchant with three processors might end a year-end close with three or four cross-month batches in transit, each from a different processor, each funding on a different January day.

Refunds, chargebacks, and fees show up in this article's later sections; settlement timing is purely about when money moves. Once the timing facts are recorded as in-transit lines, the rest of the variance work happens against the matched batches.

The reconciliation procedure and the spreadsheet schema

The merchant statement to bank reconciliation is five steps applied to per-batch rows.

1. Pull the source documents. For each MID, the close-month merchant statement. For the operating account, the bank statement covering the close month plus the first several business days of the following month — long enough to capture cross-month settlement.
2. Extract every batch and every deposit into rows. One row per batch on the merchant side, one row per deposit on the bank side. Don't summarize; the per-batch detail is what the reconciliation matches against.
3. Calculate the expected deposit per batch using the fee-shape rule that applies to that MID — the deducted-at-deposit equation or the gross-deposit equation from the previous section.
4. Match each batch to its bank line by funded date and amount. Most ties are clean. The remainder become diagnostic work.
5. Diagnose every unmatched line using the variance-reason decision tree, which the next section walks in detail.

The schema below is the worksheet that holds the work. Each row represents one batch (merchant-side) or one bank deposit (bank-side); the matching happens by linking rows that share a funded date and amount. The columns:

• Date — the batch close date for merchant-side rows, the bank deposit date for bank-side rows. A row-source flag (or two parallel sheets) keeps the two clear.
• Processor — Stripe, Worldpay, Heartland, Square, PayPal, etc. Named explicitly because the variance check happens per processor, not against the operating account total.
• MID — the merchant identifier, used when several locations share a processor.
• Batch ID — the processor's batch reference, the unique key for tracing back to the statement.
• Gross Sales — the batch's gross sales total before any subtractions.
• Refunds — refunds applied to this batch's day.
• Chargebacks — chargebacks netted against this batch (if the contract reduces the deposit at chargeback time) or zero (if chargebacks appear as separate negative batches).
• Fees — daily-deducted fees on a deducted-at-deposit contract; zero on a gross-deposit contract, where fees post once at month-end as their own row.
• Reserve / Holdback — the per-batch reserve subtraction, where applicable.
• Expected Deposit — Gross − Refunds − Chargebacks − Fees − Reserve. The calculated tie target.
• Funded Date — when the deposit actually lands at the bank.
• Actual Deposit — the bank line amount on the funded date.
• Variance — Expected minus Actual.
• Variance Reason — the decision-tree code from the next section, or a short note. Clean rows leave this blank.

A worked-out row reads cleanly. A Stripe batch closing March 28 with $12,400 gross sales, $300 refunds, $0 chargebacks, $360 fees, and $0 reserve produces an expected deposit of $11,740. If the bank shows a $11,740 line on March 30 funded date, variance is zero and Variance Reason stays blank. If the bank line for March 30 reads $11,640 instead, variance is $100 and the row goes to the diagnostic step — most likely a refund or chargeback that hit after the payout was calculated, but identifying the cause is the next section's job.

The schema is append-only by row. Every batch and every bank line is its own row. When the acquirer nets several batches into a single bank deposit (common on traditional acquirers — three daily batches funded as one Wednesday deposit), or when one batch funds in two pieces (less common but happens with split funding), the schema captures the linkage with a shared match-group reference rather than collapsing data. Match-group references are a simple sequential ID — MG-001, MG-002 — that links all rows that net to the same matched amount. Rolling everything up by collapse loses the per-batch detail you need when a future reviewer asks why one bank deposit covered three days of activity.

The schema requires every batch row from the processor statement and every deposit line from the bank statement, which is where the workflow tends to bottleneck. Bank lines come from the bank feed easily enough (the Honest Software section later goes into this). Merchant statement batches are where things slow down — for PSPs with direct connectors the data flows automatically, but for traditional acquirer statements delivered as PDFs, every batch row has to be lifted off a printed page. For Heartland-banked merchants this is the typical bottleneck; if that's your setup, you can extract Heartland merchant statements to a spreadsheet before populating the schema, which is faster than working from the printed batch summaries directly.

The variance-reason decision tree when a line won't close

When the Variance column won't zero out, six causes account for nearly every stuck row. Walk them in this order — the most common timing-side causes first, the content-side causes next, the long-tail descriptor cause last:

1. Cross-month batch (timing)
2. Chargeback reversal
3. Fee-timing mismatch
4. Refund offset
5. Holdback or rolling reserve
6. Descriptor or processor misallocation

Cross-month batch. Symptom: a merchant batch with no matching bank line on the expected funded date, and the next month's bank statement carries the deposit. Resolution: post the batch as a deposit-in-transit on the close month, code the row's Variance Reason as "timing — cross-month," and clear the in-transit line the following month when the deposit lands. Half of "my close doesn't tie" cases stop here.

Chargeback reversal. Symptom: a bank deposit smaller than expected by a clean per-transaction amount, with no refund line on the merchant statement for the period and no other obvious adjustment. The chargeback usually appears on the merchant side as a separate negative batch (sometimes days or weeks after the original sale), and on the bank side as a deposit reduction with no per-chargeback memo. Reconciling a chargeback against the bank deposit is fundamentally about making that silent offset visible — the deposit shrank, but no per-event line on the bank side explains it. Resolution: trace the chargeback row from the merchant statement to the affected batch, record the chargeback amount in the Chargebacks column on the matching batch row, and book the journal entry — debit chargeback expense (or sales returns and allowances, depending on chart-of-accounts convention) and credit accounts receivable or sales clearing for the disputed amount. Confirm separately whether the processor charged a chargeback fee (commonly $15 to $25 per case) and book that as additional processor-fee expense.

Fee-timing mismatch. Symptom on a gross-deposit-model contract: every daily line tied cleanly, but a single late-month bank debit didn't appear in the schema. The debit is the month's processor fees, posting once on its own. Resolution: add the monthly fee debit as a separate row in the schema, with the fee invoice number in the Batch ID column and a negative Expected Deposit. The variance closes immediately. The same symptom on a deducted-at-deposit contract usually means an instant-payout fee or a separately billed assessment that wasn't anticipated; the resolution is the same — add the row.

Refund offset. Symptom: a partial-day variance equal to a refund processed that day. On a deducted-at-deposit contract, the refund reduced the day's payout silently. On a gross-deposit contract, it arrived as a separate negative batch. Resolution: confirm the refund was captured in the Refunds column on the matching batch row. If it was missed at extraction (common when refunds appear on a separate page of the merchant statement), add it now.

Holdback or rolling reserve. Symptom: every batch is short by a consistent percentage — most commonly 5 percent or 10 percent of gross. High-risk merchants and merchants in the first year of a new processor contract are the typical candidates. Resolution: add a Reserve / Holdback column subtraction equal to the contractual reserve rate to each batch row, recalculate Expected Deposit, and track the reserve account separately as a balance-sheet asset. The reserve releases on the contract's stated cycle (typically 6 to 12 months later, sometimes longer) and reconciles as its own line at release — debit cash, credit the reserve receivable. The mistake to avoid is treating the reserve as a fee; it is a deferred receivable, not an expense.

Descriptor or processor misallocation. Symptom: a deposit on the bank side that doesn't tie to any expected batch, or an expected batch with no matching bank line, on a multi-processor account. The bank descriptor was misread and the deposit got attributed to the wrong processor in the schema. Resolution: cross-check the bank descriptor — Stripe deposits show as STRIPE TRANSFER, Square as SQ * or SQUARE INC, Worldpay variants as MERCH BNKCD DEP or WORLDPAY, Heartland as HEARTLAND PYMT SYS, PayPal as PAYPAL TRANSFER. Reassign the bank line to the correct processor and the variance closes on both sides. The next section walks the multi-processor split in full.

If a variance can't be tied to any of these six after a focused look, post it to a clearing or suspense account flagged for follow-up — not because clearing accounts are the right answer, but because a documented unresolved variance with a follow-up date is acceptable close-cycle hygiene and an unattributed difference left inside the reconciliation total is not. The follow-up gets resolved when the next month's processor statement or a vendor-support ticket surfaces the missing context.

Multi-processor splits when one operating account holds many MIDs

The realistic merchant has more than one processor. A retailer with in-person card terminals on a traditional acquirer, an online checkout on Stripe, and a third channel for events on Square or PayPal does not get four bank accounts. They get three to six processor-MID combinations depositing into one operating account, and the multi-processor deposit reconciliation has to split the bank deposits by processor before any per-batch tie works. The split is the work.

Bank descriptors do most of the splitting, because every processor's bank narrative is distinguishable once you know what to look for. The wording varies by acquirer and bank, but the patterns are stable enough month-over-month to map once and reuse:

• Stripe — STRIPE TRANSFER, often with a payout ID suffix.
• Square — SQ * or SQUARE INC, sometimes with the Square location number.
• Worldpay — MERCH BNKCD DEP, WORLDPAY, or the bank-card-services descriptor your bank uses for Worldpay-acquired deposits.
• Heartland — HEARTLAND PYMT SYS or HEARTLAND PMT.
• PayPal — PAYPAL TRANSFER or PAYPAL DES.
• Elavon, BAMS, Chase Merchant Services, TSYS — typically each has a distinctive descriptor that reflects either the acquirer name or a bank-card-deposit code. The first month of statements is enough to map them.

The map gets built once and refreshed when a processor changes acquirer or rebrands. After that, the reconciliation procedure runs per processor: filter the bank-side rows by the processor's descriptor, filter the merchant-side rows by the Processor column, and reconcile within each filtered slice. The Variance check happens per processor, not against the operating account total — a $0 variance in aggregate can hide a $500 Stripe overstatement and a $500 Worldpay understatement that cancel each other in the rollup.

The multi-MID-same-processor case is structurally similar but uses a different column. A franchise or multi-location operator commonly has several MIDs of the same processor — one per store, or one per legal entity — and each MID issues its own monthly statement and funds separately to the same operating account. Here the Processor column doesn't do any splitting work because every row has the same value; the MID column carries the load instead. Build the descriptor map per MID rather than per processor, since the bank line for a Heartland MID in Phoenix and a Heartland MID in Chicago will arrive with two different descriptors that differ in the trailing identifier. When the per-MID detail needs to be consolidated for fee analysis or chain-level reporting, you can aggregate merchant statements across multi-MID franchise locations before slotting each MID's batches into the schema.

Two distinctions catch newer practitioners on multi-processor reconciliations and create phantom variances if they're missed:

Gateway versus processor. A payment gateway like Authorize.Net, NMI, or Spreedly routes transactions to an underlying processor, but the deposit comes from the processor — not the gateway. A merchant on an Authorize.Net account back-ended by Worldpay funds with a Worldpay descriptor on the bank side, even though the operational interface is Authorize.Net. Reconciling the gateway's transaction reports against bank deposits will fail; reconcile against the underlying processor's merchant statement instead.

Aggregator versus direct merchant. Stripe, Square, and PayPal are payment aggregators — they hold a master merchant account with the network and fund sub-merchants from it — and their settlement cycles, fee shapes, and reserve policies often differ from a direct-merchant traditional acquirer arrangement on the same brand. A Stripe-funded Visa transaction settles through Stripe's payout cycle; a Worldpay-funded Visa transaction settles through Visa's network cycle. The card brand is the same; the deposit timing and shape are not. Restaurant operators run into a sharper version of this when tying Toast, Clover, and Square daily settlements to the bank — tips routed through the deposit, multi-batch days, and holdbacks all change the per-batch arithmetic.

The operational discipline is straightforward: build the descriptor map once, reconcile per processor and per MID inside the same workbook, and roll up to a master variance only after each slice has tied independently.

What bank feeds and accounting software actually reach

The bank side of this reconciliation is largely automated for everyone, and the merchant side is largely automated for some processors and largely manual for others. Knowing exactly where the line falls is the difference between a reconciliation that closes in an hour and one that eats a day.

Bank feeds populate the bank columns. QuickBooks Online, Xero, Sage Intacct, and NetSuite all import bank lines from the operating account automatically — date, descriptor, amount. That populates Date, Funded Date, and Actual Deposit on the bank-side rows of the schema with no manual entry. If your operating account is at a major US bank, the bank feed is mature and the lines arrive cleanly. This is real automation worth using.

Processor-direct connectors populate the merchant columns for some processors. Stripe has direct integrations into QuickBooks and Xero that import payouts with batch-level detail — gross sales, refunds, fees, and the payout amount per batch. Square has direct integrations into QuickBooks and Xero. PayPal connects to both. For Stripe, Square, and PayPal merchants the extract step is automated end-to-end and the reconciliation usually closes inside the accounting software with no spreadsheet at all — assuming the connector is healthy and the close period falls inside the connector's reconciliation window. When connectors break (auth tokens expire, API rate limits hit during a backfill, the connector's data model lags a Stripe product change), the manual fallback is the same procedure this article describes; the connectors solve 90 percent of cases when they work and 0 percent of cases when they don't.

Coverage stops at PDF-only acquirer statements. Worldpay, Heartland, Elavon, BAMS, Chase Merchant Services in many configurations, TSYS, and various Fiserv-acquired contracts deliver the monthly merchant statement as a PDF — sometimes through a portal that requires per-MID login, sometimes by email, occasionally by physical mail. NetSuite cash management does not import these. QuickBooks and Xero bank-rec flows do not import these. The reconciliation needs the per-batch detail — gross sales, refunds, chargebacks, fees, reserve, batch ID — and none of those columns populate from the bank feed. They come off the merchant statement, and on a PDF statement the practitioner either keys the data row by row or runs a structured extract over the PDF.

This is the load-bearing prerequisite for the entire reconciliation. The expected-deposit calculation needs the per-batch fields. Without them, no Variance column. Without a Variance column, no decision tree. The reason a multi-processor reconciliation that "should be quick" can eat half a day is that one or two of the processors deliver PDF statements and the per-batch detail has to be lifted off them before any matching can start.

The product side of this is straightforward. Automated merchant and bank statement extraction handles the manual extract step — turning the merchant statement PDF into the per-batch rows the reconciliation works on. The interaction model is a single prompt field over a file upload. A user uploading a Worldpay or Heartland monthly statement writes something like "extract one row per daily batch with batch ID, date, gross sales, refunds, chargebacks, fees, and net deposit; columns named exactly as listed" and gets back a structured spreadsheet matching the schema columns. A multi-MID batch of statements runs through the same interaction, and bank statement PDFs go through the same prompt-and-upload pattern when the bank feed isn't an option. Output is to Excel, CSV, or JSON. There are no templates to configure. The output is the rows the reconciliation needs; the reconciliation logic still belongs to the practitioner.

For practical purposes: use bank feeds for the bank side, use direct PSP integrations where they exist for Stripe, Square, and PayPal, and budget the structured-extract step for any PDF-only acquirer statement in the channel mix. The mix of automation is what determines how much manual work a reconciliation actually carries — and a merchant whose channel mix is all PSP-integration-friendly will close in minutes, while a merchant whose channel mix includes two traditional acquirers with PDF statements is in the manual-extract bucket no matter what accounting software they run.

Documenting the reconciliation for close

The deliverable from this work is a close file, not just a balanced spreadsheet. What goes into the file shapes how survivable it is — to an auditor, to a controller reviewing the close, to next month's reviewer trying to remember what last month did.

A complete close file for the merchant deposit reconciliation contains:

• The populated schema spreadsheet covering every processor and every batch in the close month, with cross-month batches flagged as deposits-in-transit and carried into the next month.
• The source PDFs for every processor's monthly merchant statement and the bank statement for the operating account, filed alongside the workbook.
• Reserve and chargeback subledgers where the merchant has rolling reserves or material chargeback activity. The reserve subledger tracks deferred receivables; the chargeback subledger captures the disputed transactions and their disposition.
• Journal entries summarized by processor. Per-processor: gross sales debited to receivables clearing (then cleared to revenue or held as deferred depending on revenue-recognition timing), processor fees debited to processor-fee expense, chargebacks debited to chargeback expense or sales returns and allowances, reserve amounts debited to the reserve receivable, and the deposit credited to operating cash. The journal-entry summary should reconcile to the schema's per-processor totals in one step.
• A one-page close memo listing every variance over the materiality threshold the firm uses, with the decision-tree disposition for each — timing, chargeback, fee timing, refund offset, reserve, descriptor — and the follow-up date for any variance posted to suspense. Variances under the materiality threshold can be summarized; variances over it should each be named.

The merchant deposit reconciliation is one piece of a larger month-end close — bank reconciliation runs alongside it, AP and AR close on their own cadence, payroll and accruals on their own. The cleanest filing places this reconciliation inside the broader workflow rather than as a standalone document. The AP month-end close checklist this reconciliation slots into describes the rest of the close cycle and the order each piece typically runs.

At year-end, this reconciliation also becomes the input to the 1099-K reconciliation. The IRS-reported 1099-K from each processor reports gross payment volume for the calendar year, and the gross sales totals reconciled here become the comparison numbers — if the year's reconciled gross sales for a processor don't match the 1099-K to the dollar, the gap needs to be explained before the bookkeeping records can be closed against tax filings. The full procedure for the year-end 1099-K reconciliation against bookkeeping records is its own job, but the monthly schema files feed it directly.

The audit-ready test for a close file is concrete: an unfamiliar reviewer should be able to pick up next year's audit, select any single batch from any month's reconciliation, and trace it from the merchant statement, through the schema row, to the bank deposit, with the variance disposition documented. If the reviewer can do that without asking questions, the file is complete. If the reviewer has to ask why a March batch is sitting in April's bank statement, or where the monthly fee debit is coming from, or which Worldpay descriptor maps to which MID, the documentation is incomplete regardless of whether the variance number on the summary line reads zero.