PSPs Missing Fees — Report documentation

Purpose

The PSPs Missing Fees report (sometimes titled Potential Missing Fees in exports) helps finance and fee operations find payment activity where fees may not be recorded correctly. It highlights combinations of PSP and account that have successful payment volume but show no fee in the buy-side fee data, and it lists PSP accounts that do not follow the usual account naming pattern so configuration and data quality can be reviewed.

What data this report uses

This report uses PSP Fee v3 only. That data source holds buy-side volume and fees by organisation, PSP, account, method, date, and related dimensions—one row per detailed grain, with successful amounts and total fee among other measures. For full field definitions and how amounts and fees are defined, see the PSP Fee v3 — User Guide.

Report-level filters

These controls apply to the whole report page and narrow which rows from PSP Fee v3 are in scope.

Filter	What it does	How to use it	When it's useful
Date range	Limits rows to the calendar dates you select (based on the transaction date used in the report).	Choose a start and end date (e.g. one month).	Reviewing a specific period, closing a month, or focusing on recent gaps.
PSP	Restricts the report to one or more payment service providers.	Pick PSP values from the dropdown (or “all” if available).	Drilling into a single PSP or comparing a small set.

You can Export the report when you need a file copy of what is on screen.

Resource-level filters

Some charts apply their own filters in addition to the report-level date and PSP settings. You normally do not change these when viewing the report; they define how each visual is intended to work.

Filter	Resource	What it does
Exclude PSP	The summary view that shows Successful Transaction Amount and Total Fee by PSP and account	Removes a fixed list of PSPs (for example test or non-production style providers) so they do not appear in this missing-fee check.
Fees missing	Same summary view	Keeps only rows where there is successful payment volume but no positive total fee, so every line is a candidate “missing fee” case.
psp acc not standard	The table PSP Accounts not following standard	Limits the table to PSP accounts whose names do not match the long, multi-part “standard” account code pattern. Shorter or differently shaped account codes stay in the list so you can review exceptions.
excl lids	Same table (PSP Accounts not following standard)	Applies an extra exclusion rule defined on the chart (for example to hide certain internal or test identifiers).

Both main visuals use the report’s transaction date field for time (the same calendar date dimension as in the PSP Fee v3 user guide).

Successful volume with no recorded fee (summary)

This part of the report is a pivot-style summary backed by PSP Fee v3. Each row is a PSP and PSP account that passes the Fees missing logic: there is successful transaction volume in the period, but Total Fee shows as zero (no fee recorded). Exclude PSP removes named providers from this list so the focus stays on live, in-scope PSPs.

Column / area	Meaning
PSP	The payment service provider name.
PSP Account	The specific PSP account or route identifier.
Successful Transaction Amount	The amount of successful payment volume for that PSP and account in the selected period (in the currency shown on the report, typically euros).
Total Fee	The combined fee for that row in the fee data. On this report it should read as zero for every line, by design—that is what flags a potential missing fee.

Use this block to see where volume exists without a matching fee line, before you open fee configuration or the underlying data.

PSP Accounts not following standard

This table also uses PSP Fee v3. It lists PSP accounts whose naming does not follow the usual long, underscore-style standard codes (those standard-style codes are filtered out by psp acc not standard). Rows include a month, PSP, PSP account, successful amount, and total fee, with excl lids removing additional rows per the chart setup.

Column	Meaning
Month	The calendar month of the activity on the row.
PSP	The payment service provider.
PSP Account	The account name or code (often shorter or differently formatted than the main standard list).
Success Value	The successful transaction amount for that month and account (same underlying idea as “successful volume” in the user guide, shown under this label on the report).
Total Fee	The total fee charged for that row. When this stays at zero while Success Value is not, it warrants the same kind of fee review as the summary above.

A Grand total row sums Success Value (and Total Fee) for the rows shown. Use this table together with the summary to separate “no fee recorded” from “account name does not match the standard pattern”—both can drive follow-up with product, integrations, or finance tooling.