What reports exist?
Everything the platform does writes to one ledger, and Reporting is the read side of it: underwriting decisions become merchants, transactions become batches, batches become deposits, and disputes and residuals land against the same keys. Whatever layer of QorCommerce touched the money, the answer is queryable here.
Six families now cover the money end to end: settlement, deposit, fee, dispute, residual, and the new sponsorship family. Settlement reports show every batch with its transactions; deposit reports show what actually hit the bank account and which batches funded it.
Fee reports break out interchange, network fees, and processing costs line by line, no blended “processing fees” bucket. Dispute reports track every chargeback and its deadline, and residual reports give portfolio operators the per-transaction math behind each payout.
What does sponsorship reporting cover?
Both sides of the sponsorship table, from the same ledger. Sponsor banks get a dedicated bank reports view built for oversight, scoped to one sponsor at a time. Standing: program compliance audit reporting, BIN-level exposure, and boarding and underwriting attestation ("who is on my BIN," answered). Activity: new-merchant approvals and declines, remediation actions per BIN, and per-sponsor settlement reconciliation. Exposure: reserve and funding exposure across the book, and sanctions-screening cuts. Every report delivers as PDF or CSV and is schedulable, so it arrives on the bank's cadence without anyone remembering to run it. And the bank does not have to wait on us to run any of it: the Sponsor Portal gives a bank's own team self-serve, read-only access to the full set, scoped to their program, with no passwords to manage. Access is granted and revoked by QorPay, sign-in is a one-time link and code, and even the portal's access trail is itself a report the bank can pull. Ask another processor to show you that. Sponsored ISOs and agents are next: a standing view of their own book, their ratios, and where they sit against program thresholds, read from the same rows the bank reads, is being built now, and portfolio-level visibility is available through Channels today. When every party looks at one ledger, program review stops being a data-gathering exercise and becomes a conversation about the numbers, because nobody is arguing about whose numbers.
Merchants are next. A new generation of merchant reports is rolling out now, with more landing through the year. If there is a report your month-end needs and does not have, tell us what it looks like; it may already be on the list, and if it is not, you just put it there.
What does the account ledger look like?
A real double-entry ledger, not a transaction list wearing a ledger costume. Every event posts with its counterpart and a running balance, viewable by day, week, or month and exportable to CSV, so the books balance because they are books, not because someone made them balance. Reserves get their own ledger with release status and release dates, so "how much is held and when does it come back?" is a column, not a support ticket.
Tax season is covered by the same data: 1099-K reporting builds gross-volume totals and the monthly breakdown from the ledger itself, split card-present versus card-not-present, figures that tie to the deposits you can trace, because they come from the same rows.
How current is the data?
Transaction activity is visible as it happens: authorizations and captures appear in the portal and the API in the flow of processing, not in a nightly file. Settlement and deposit data posts as batches close and fund (TODO: verify latency of settlement data to portal).
The reporting reads the same ledger the processing writes. There is no export pipeline between “the processor’s system” and “the reporting product,” because they are the same system, operated by QorPay.
What is Refleqtion?
Refleqtion is QorCommerce’s near-realtime transaction injection API: it accepts transaction events that originate outside the platform’s own authorization path and posts them into QorCommerce as they happen. The two big sources are semi-integrated card-present devices, where the terminal runs the transaction and Refleqtion carries it into the platform, and inbound transaction webhooks from connected systems sending their activity into Qor.
Injected activity lands on the same ledger as natively processed transactions, so it settles, reconciles, and reports identically: one reporting view whether the transaction started in a browser, at a counter, or in a partner system’s webhook stream. The Refleqtion docs cover the API and event formats.
How do you reconcile deposits?
By trace, not by guess. Every deposit links to the batches that funded it, every batch to its transactions, and every transaction to its fees, so the question “why is this deposit $12.40 short?” has a line-item answer.
The chain runs both directions. Start from a bank statement line and drill down to transactions; start from a transaction and follow it forward to the deposit that paid it. Month-end close stops being an archaeology project.
Deposits carry their full lifecycle in the portal (requested, processing, processed, failed, denied, returned), with wire trace numbers attached, reserve movements shown as explicit entries (sent to reserve, released from reserve), and a funding queue view of scheduled and funded payouts with hold and fee-collected flags.
Can I pipe data to my warehouse?
Yes. Everything in the portal is reachable over the REST APIs (JSON out, keyed auth, the same interface your payment integration already uses), and reports export in machine-readable formats for batch pipelines.
Platforms and ISOs commonly sync transactions, settlements, and residuals into their own warehouse on a schedule and build internal dashboards there. The response handling guide documents the payload structures to build against.