What an Automated Residual Audit Actually Checks (Line by Line)

Demystifying the Audit

Agents hear "automated residual audit" and reasonably ask what is actually happening. Fair question.

An automated residual audit in Residual Genius is a structured sequence of comparisons between two documents you provide: your Schedule A and your processor residual report. Every step is deterministic, same inputs, same outputs. No judgment about intent. No assumptions about industry norms. Your contract is the baseline. The report is the claim. The audit surfaces where they diverge.

This article walks through what the audit checks, line by line, in the order the engine processes your data. No marketing fog. No fabricated case studies. Just the mechanics.

Step One: Ingest and Normalize the Residual Report

Before any comparison happens, the raw report must become structured data.

Format Handling

Processor residual reports arrive as CSV exports, Excel files, PDFs, and portal downloads. Column names, sign conventions, date formats, and merchant identifiers differ across formats. The ingestion layer maps columns from the uploaded file to a canonical schema, merchant ID, line item category, income amount, expense amount, net amount, actual residual paid, reporting period.

You do not manually label columns. The engine recognizes common processor report layouts and prompts for mapping when a format is new. Once mapped, the format is remembered for future uploads.

Sign Normalization

Some reports show expenses as negative numbers. Others show them as positive with a debit indicator. Some show income as gross before expenses; others show net only. Normalization converts all amounts to a consistent representation, income, expense, net, and actual residual as separate fields, so downstream calculations do not depend on how the processor chose to format the export.

Period Identification

The audit scopes reconciliation to the reporting period covered by the uploaded report, typically a board month. All calculations and comparisons operate within that period. Multi-period reports are split or scoped to the selected period before comparison begins.

Step Two: Ingest and Store the Schedule A

Your Schedule A is the source of truth for the entire audit. It is stored as a versioned rate reference, not a one-time input discarded after parsing.

Rate Table Extraction

The engine reads rev-share percentages by line item category from your Schedule A, interchange, PIN debit, monthly fees, transaction fees, gateway, PCI, equipment, and any other categories defined in the document. Each percentage is associated with the rate table version and effective date from the Schedule A.

Version Management

If your Schedule A has been amended, new rates effective January 2024, promotional rates for merchants boarded in Q1, tiered structures with volume thresholds, each version is stored separately. The audit resolves which version applies to each merchant based on the merchant's boarding date and the reporting period being audited.

This is the step that manual spreadsheet reconciliation gets wrong most often. Applying the current Schedule A to every merchant regardless of boarding date produces false exceptions on legacy merchants and missed variance on merchants whose rates changed mid-relationship.

Expense Treatment Rules

Where your Schedule A specifies how expenses affect the rev-share base, net versus gross, pass-through only, expense-line rev-share, those rules are stored per category. The calculation engine applies category-specific rules rather than a single net-times-percentage formula for every line.

Step Three: Match Merchants

The report contains merchants. Your portfolio contains merchants. The audit matches them.

MID-Level Matching

Primary matching uses merchant ID numbers, the unique identifier assigned by the processor. Each row on the report is associated with a MID. The audit verifies that MID against your merchant roster.

Completeness Checks

Merchants on your roster but absent from the report are flagged, not as calculation variance but as completeness exceptions. Merchants on the report but not on your roster are flagged as unrecognized. Both warrant review: a missing merchant may be closed, reassigned, or on a hold status. An unrecognized merchant may be a new boarding not yet in your records or a MID assigned to a different agent code.

Agent Code Verification

Where agent codes appear on the report, the audit verifies they match the agent code on your Schedule A. A report filtered to a different agent code means you are reconciling someone else's residuals, a completeness error that invalidates the entire comparison until corrected.

Step Four: Calculate Expected Residual, Line by Line

This is the core of the audit. For every merchant on the report, for every line item category on that merchant's detail, the engine calculates expected residual and compares it to actual residual paid.

Line Item Identification

Each row on the residual report represents a line item, interchange income, interchange expense, PIN debit income, monthly statement fee, per-transaction authorization fee, etc. The engine identifies the category and maps it to the corresponding Schedule A rate table entry.

Unmapped line items, categories on the report with no corresponding Schedule A entry, are flagged separately. They may be pass-throughs you accepted without rev-share, or categories worth asking about. The audit does not silently ignore them.

Rate Version Resolution

For each merchant, the engine determines which Schedule A version is effective for the reporting period based on boarding date and effective date ranges. The rev-share percentage from that version is applied to the line item.

Base Calculation

For income lines where rev-share applies to net: expected base equals income minus associated expenses on that line item. For lines where the Schedule A specifies gross-based rev-share: expected base equals income before expense deduction. For expense lines with their own rev-share: expected base equals the expense amount.

The category-specific rules stored in step two govern which formula applies.

Expected Residual

Expected residual equals expected base times rev-share percentage. This is the amount your contract specifies you should earn on that line item for that merchant in that period.

Variance Calculation

Variance equals actual residual paid minus expected residual. Negative variance means you received less than your contract specifies. Positive variance means you received more. Both are surfaced, positive variance may indicate a configuration error in your favor or a minimum/cap override worth understanding.

Zero-Net Handling

When income equals expense on a line item, net is zero and expected residual is zero. The audit does not flag zero-net lines as variance, a common spreadsheet mistake that floods you with false exceptions. Only lines with material net and a non-zero expected residual generate calculation variance.

Step Five: Classify and Group Exceptions

Raw variance on thousands of line items is unusable. The audit classifies and groups exceptions for human review.

Materiality Threshold

Immateriall variance, below a configurable dollar threshold per line item, is suppressed from the exception report. Rounding differences and sub-dollar noise do not clutter the output. Material variance surfaces.

Line Item Grouping

Exceptions grouped by line item category reveal systematic patterns. If forty-seven merchants show negative variance on interchange net, the audit groups them: same category, same direction, merchant count, total impact, average variance per merchant. This is the highest-signal output of the audit, systematic patterns that point to configuration differences worth raising with your processor.

Merchant-Level Detail

Within each group, merchant-level detail is available: MID, DBA, expected amount, actual amount, variance, boarding date, rate version applied. You can drill from pattern to individual merchant for documentation.

Positive and Negative Variance

Both directions are reported. Agents who ignore positive variance miss configuration that pays above their Schedule A, which may be temporary, or may indicate a minimum or rate you had not modeled.

Step Six: Generate the Exception Report

The output is a structured exception report designed for review and documentation, not a raw data dump.

Summary Layer

Total merchants audited. Total line items compared. Exception count by category. Estimated total variance for the period, positive and negative separately. Merchant penetration per exception group, what percentage of your portfolio is affected.

Detail Layer

Per merchant, per line item exceptions with full calculation shown: income, expense, net, rev-share percentage, rate version, expected residual, actual residual, variance. Every number is traceable to the Schedule A and the report.

Pattern Layer

Systematic exception groups ranked by total impact. Line item category, merchant count, average variance, total variance, rate version distribution. This is the layer you bring to a processor conversation, not individual merchant anecdotes, but documented patterns with contract references.

What the Audit Does Not Check

Transparency about scope matters as much as transparency about process.

The Audit Does Not Verify Merchant Activity

It reconciles what the report shows. It does not verify that reported volume matches actual transaction activity, that is a separate merchant-level audit.

The Audit Does Not Interpret Ambiguous Contract Language

If your Schedule A says "net of applicable fees" without defining "applicable," the audit applies the most literal interpretation and surfaces variance when the report differs. Contract ambiguity is flagged by its financial impact, not resolved by the engine.

The Audit Does Not Contact Processors

No emails, no dispute letters, no escalations from the audit itself. Residual Genius produces the comparison. You decide whether and how to raise findings. All outbound recovery and dispute sending is disabled by default, mediation letters, digest sends, and processor alert emails stay off unless you turn them on. A completion notification email may send when your audit finishes if email delivery is configured for your account.

The Audit Does Not Assume Bad Faith

Variance is reported as arithmetic difference, not as allegation. The exception report shows expected amount, actual amount, and variance, not "processor underpaid you." Neutral by design.

How This Compares to Manual Reconciliation

Every step above is what a thorough agent would do manually, if they had unlimited time and perfect attention. The difference is completeness and repeatability.

A manual spot-check of five merchants performs steps four and five for five accounts. An automated audit performs them for every account, every line item, every month, with version-aware rate matching, category-specific calculation rules, and systematic pattern grouping that spreadsheets cannot replicate without extraordinary effort.

Our article on why manual reconciliation fails covers the scale problem in detail. The residual audit software page describes the product workflow from upload to exception report.

See the Audit on Your Own Data

Reading about what an audit checks is useful. Running one on your portfolio is better.

Upload your Schedule A and your latest residual report. Watch the engine ingest, match, calculate, and group. Review the exception report. Decide what the variance means and what, if anything, to raise with your processor.

The audit is not a black box. It is your contract, compared to your report, line by line. That is the entire product.

Start your free residual audit, see exactly what an automated audit checks on your data. No upfront payment, then $247/mo unless you cancel.