By Eric Kuvykin. Substantially revised October 17, 2026. The original publication date and URL are retained.
Write a definition before building the chart
Two dashboards can show different totals without either one being broken. They may count different events, periods or account populations. Before using a payment metric to judge performance, write down what it counts and where the underlying record comes from.
For each metric, specify the event, denominator, date basis, time zone and exclusions. “Success rate” is incomplete unless the business knows whether it refers to attempts, completed orders, authorizations or settled payments. Keep the definition close to the report so it survives staff changes.
Use a small source-to-summary test
Choose a few actual orders containing an ordinary sale, a failed attempt, a retry and a refund. Trace how each appears in the order system, provider report and bank record. The test should explain why one customer purchase may produce several payment events.
Preserve original exports and document transformations in the working file. Do not change a source date or remove an inconvenient row to force agreement. If a cutoff difference explains the result, record the bridge between the reports.
Keep refunds and disputes distinct
A refund request, an initiated refund and a completed financial adjustment may be different events in the workflow. Define which one the report uses. Keep disputed principal, service fees and ordinary refunds separate when they answer different operating questions.
For a business with Florida, New York and New Jersey accounts, retain the legal entity and merchant account in the data model. A combined chart should still allow a reviewer to identify which account accepted the sale and received the deposit. Do not let a common brand name erase that distinction.
Review access and usefulness
Limit exported fields to what the analysis needs and restrict access appropriately. The PCI Security Standards Council’s merchant resources offer context for reviewing payment-data handling with providers and specialists. An operating dashboard should not create an uncontrolled copy of sensitive payment information.
Assign an owner to each definition and review it after a software or channel change. If a vendor changes a report field, test the source-to-summary bridge again before comparing the new series with the old one.
End a weekly review with a small set of decisions and unresolved questions. A metric is useful when another trained person can reproduce it and understand the action it supports. A polished chart without a stable definition can create confidence without improving the business’s understanding.
References and related reading
Primary resource checked for this review: PCI Security Standards Council’s merchant resources. Confirm the current requirements and implementation with the responsible provider or appropriate adviser.
Continue with Payments Data: Build a Weekly Operating Review From Source Records and How to Read a Merchant Processing Statement Without Losing the Detail.
For state and local business resources alongside this operating checklist, use the Florida, New York and New Jersey reading paths on All State Merchants.
