How to read a Paysafe residual report

Paysafe, whose US ISO business includes the former iPayment platform, does not send one residual file. It sends a package: five workbooks for the same month, each describing the same merchants at a different level of detail. The first time an office receives it, the natural reaction is to open the biggest one and start summing. This guide is what to open instead, and why.

It is written from the residual package on Paysafe's US platform as we see it each month. Layouts vary between programs, so your columns may be named or ordered differently. The structure, and the traps, are the same.

What arrives each month

Five files, three shapes: two statements, two one-row-per-merchant files, and one long file with many rows per merchant. Knowing which is which is most of the job.

The two statements

The ISO Summary is headed with the month, "Residual Statement", and the ISO's name. Below that is a table: Item down the left, and Visa, Mastercard, Amex OptBlue, Discover, Bankcard and Debit EBT across the top. The first rows are Sales Volume, Authorizations and Transactions. Then every billing item, one row each: Annual, Assessment by brand, Association by brand, AVS, Batch Header, Chargeback, CPU, DIAL, Discount by brand, Gateway, Inactivity Fee, Interchange by brand, Interchange Clearing, Monthly items for each add-on product, Statement, Wireless and so on.

The Agent Summary is the same statement for one agent code, headed with that code and the agent's name. There is one file per code Paysafe knows about. These are the processor's view of who sold what. As with every processor, that is a starting point for assigning merchants to agents and not the last word, because accounts get reassigned and shared inside your office and the code does not follow.

Use the statements to tie out. Do not pay from them: they have no merchant on them.

Merchant Summary Detail: the file to pay from

One row per merchant, and wide: well over a hundred columns. Reading left to right:

Who the merchant is

Date, Merchant Number, Merchant Name, then four processor identifiers: an agent number and a sales rep number from each of two Paysafe systems (the columns are labelled Oracle and iWorkflow), then Sales Rep.

• Merchant Number is the key. Match on it, never on name.
• The agent and sales rep numbers are how Paysafe attributes the merchant. Two systems, two sets of numbers, and they can disagree with each other. Use whichever your agreement with Paysafe is keyed on, record it once, and assign merchants to agents in your own system from there.
• Date is the processing month. Check it first.

Every fee, one column each, by card brand

Then the long middle: a column for each billing item, split by brand where the brand matters. Assessment, Association, AVS, CPU, DIAL, IP and Settlement Fee each appear separately for Visa, Mastercard, Discover and Amex Opt Blue. Discount appears for those and for the debit networks. Interchange and Interchange Clearing by brand and network. Monthly product fees for each add-on the merchant has: gateway, mobile, virtual terminal, security package, regulatory, PCI. Statement, Annual, Chargeback, Inactivity Fee, Wireless, Returns and a handful more.

You rarely need these individually. They are there so you can explain why one merchant's month moved, or check that a fee you expect is being billed. On this file each column is the office's residual on that item, already net, not what the merchant paid.

Total Residual $

The last column. It is the office's profit on the merchant for the month, after Paysafe's split, and it is the number agent splits are calculated from. Since it is already the ISO's share, enter it as Total Profit with the processor split at 100% when you calculate. What happens next is in How to calculate ISO residuals.

Merchant Detail Horizontal: the same merchants by card brand

Also one row per merchant, but arranged differently. The top header row names the groups: Sales Volume, Return Volume, Discount, Interchange, Revenue, Count/Volume, Assessment Revenue and Expense, Association Revenue and Expense, Network Revenue and Expense, Buyrates, Revenue Share and Residual. The second header row repeats the card brands and fee items under each group, so the file runs to about three hundred columns. It also carries the merchant's address, MCC and open date, which the Summary Detail does not.

The two header rows are the trap. The real column names are on row two, under a group label on row one. Anything that reads row one as the header will see "Discount" and "Interchange" once each and lose the brand breakdown underneath. Read both rows and join them.

This is the file to open when an agent asks why a merchant fell: it shows whether the volume moved, the discount rate moved, or a network expense appeared. It is not the file to pay from, because its residual is spread across brands and the Summary Detail already has the total.

Merchant Detail Vertical: the file that shows the rates

One row per merchant per fee line. A merchant with a dozen billing items and several card brands has around thirty rows, so the file is long. The columns are Date, Merchant Number and Name, Open Date, Closed Date, the four processor identifiers, Sales Rep, and then the line itself: ChargeType, Fee, Card, Product, TransactionType, Revenue Amount, Expense Amount, Expense Count, BuyRate, Split, Residual Amount, Sales Volume, Sales Count, Return Sales Volume and Return Sales Count.

Three things only this file gives you:

• BuyRate is your cost on that line under your Paysafe agreement. It is the number to compare against your Schedule A when you want to know whether you are being charged what you agreed. The Summary Detail cannot answer that, because it has amounts and no rates.
• Split is the revenue share on the line, as a fraction. Different lines can carry different splits, and pass-through items carry zero.
• Residual Amount is what the office earns on the line. On most lines it is Revenue Amount minus Expense Amount, multiplied by Split. Check it on a few lines of your own file; the exceptions are pass-through and count-based items.

Closed Date is here and nowhere else in the package. A merchant with a closed date is attrition; a merchant with an open date, no closed date and no volume is a merchant to call. See Merchant attrition warning signs.

Sum this file per Merchant Number and it should equal Total Residual $ on the Summary Detail for the same merchant. If it does not, one of the two files is not the month you think it is.

Five traps in these reports

1. Summing the Vertical file by row. It has about thirty rows per merchant. Counting rows as merchants overstates the book many times over, and summing without grouping by Merchant Number gets the total right but the per-merchant numbers wrong.
2. Reading the Horizontal file's first header row. The brand-level names are on row two.
3. Paying from a statement. The ISO and Agent Summaries have no merchants on them. They tie out; they do not pay.
4. Treating Total Residual $ as gross. It is already the ISO's share. Applying your processor split to it again underpays every agent.
5. Trusting the agent numbers as your assignments. Two Paysafe systems, two sets of codes, and neither knows about a merchant you reassigned or shared last month.

A five-minute check before you calculate

1. Date on every file is the month you are closing, and it is the same month on all five.
2. Total Residual $ summed across the Summary Detail equals the residual total on the ISO Summary.
3. The count of Merchant Numbers on the Summary Detail is close to last month's.
4. Every Merchant Number with a non-zero Total Residual $ has an agent in your system.
5. Merchants with a Closed Date on the Vertical file are marked closed in your system, so a fall in an agent's pay has a visible cause.

Frequently asked questions

Which Paysafe file do I pay agents from? The Merchant Summary Detail. One row per merchant, ending in Total Residual $, which is the office's profit on that merchant for the month after Paysafe's split.

What is Total Residual $ on a Paysafe report? The last column of the Merchant Summary Detail: the ISO's share of the profit on one merchant for one month, with every fee item already netted. It is already after the processor's split, so treat the split as 100% when calculating agent pay from it.

Why does the Merchant Detail Vertical have so many rows? It has one row per merchant per fee line, and a typical merchant has around thirty lines across billing items and card brands. Group by Merchant Number before using it, and never count its rows as merchants.

Where do I find my buy rates on a Paysafe report? Only on the Merchant Detail Vertical, in the BuyRate column, alongside Split and Residual Amount for each line. The other files show amounts without rates.

What are the Oracle and iWorkflow agent numbers? Identifiers from two Paysafe systems that attribute a merchant to an agent and a sales rep. They are the processor's view of who sold the account, not your current assignment, and they do not change when you reassign or share a merchant.

Can software read these reports directly? SplitRun reads the Merchant Summary Detail as a Paysafe data source, takes Total Residual $ as the merchant's profit with the split already applied, matches merchants to agents on Merchant Number, and keeps each month so attrition and concentration show across months. See Add a data source, Upload a report and the sample agent report.