Retail Reporting & Finance Visibility First-Response Guide: The Delta Checklist for Numbers Changing Between Dashboards

Retail Reporting & Finance Visibility First-Response Guide: The Delta Checklist for Numbers Changing Between Dashboards

When your storefront shows one revenue figure, your ERP shows another, and your payment processor shows something different again, the instinct is to escalate immediately. In our work with fragmented omnichannel stacks, this is one of the most common support tickets operators raise before running any first-response checks — and more often than not, the cause is a configuration issue or a timing gap that an operator can identify and document in under 20 minutes.

This is the retail reporting and finance visibility first-response guide for exactly that window. Work through it before you open a ticket, and you'll either resolve the discrepancy yourself or arrive at IT with a complete delta sheet that cuts resolution time dramatically.

If you'd rather skip the checklist and talk through what you're seeing, book a 30-minute discovery call and bring your delta sheet.

Before You Escalate: Run The Delta Checklist

Most dashboard discrepancies — when numbers changing between dashboards are the symptom — fall into one of six categories: timezone or time-window mismatches, definitional differences in what each system calls "revenue," a failed or stalled sync job, pending transactions that haven't settled, configuration drift in currency or tax settings, or an actual integration-layer problem.

The first five are operator-verifiable. The sixth is when the handoff logic between storefront, ERP, payments, and reporting itself is broken — and that is where TkTurners closes the loop through the Integration Foundation Sprint.

Capture your time window, the systems you queried, and the specific delta before moving forward. For example: "Storefront shows $47,200, ERP shows $44,850, delta is $2,350 for the period ending April 5, 2026." That single line is the most useful piece of information in the entire escalation.

Verify Your Time Window and Timezone First

The most common false alarm in retail reporting and finance visibility comes from comparing data across different cutoff windows or timezone offsets. This one check eliminates more unnecessary escalations than any other in our experience.

Work through these items in order:

• Are all systems set to the same timezone? A storefront operating in Pacific time and an ERP operating in Eastern time will show different end-of-day totals when both are queried at the same clock hour. The ERP will appear to be missing the last few hours of business.
• Are you comparing same-day, end-of-day, or midnight-close numbers? Some retailers run a midnight cutoff; others close at their last transaction of the business day. These are not the same window, and mixing them across systems will always produce a gap.
• Did a batch job or sync complete before you pulled the report? If the storefront-to-ERP sync runs at 2:00 AM and you pulled the ERP report at 11:00 PM, you're comparing a partial-day ERP total against a full-day storefront total.
• Note the exact timestamp each dashboard was queried. Write this down before touching anything else. It is the first thing your IT team or integration partner will ask for.

Checkpoint: At this point you should have a written record of the date range, the query timestamp for each system, and the specific dollar delta. If a timezone or time-window mismatch is the cause, you can correct the comparison and close this without a ticket.

Confirm the Authoritative Data Source for Each Metric (Storefront ERP Reconciliation)

If the time window checks out and numbers are still diverging, the next most common issue in storefront ERP reconciliation is an apples-to-oranges comparison — where each system is measuring a different thing but the labels look the same.

Ask these questions before assuming a discrepancy exists:

• Which system is the authoritative source for each number you are comparing? In most omnichannel stacks, the ERP is the book of record for inventory and cost of goods, the storefront is the book of record for orders placed, and the payment processor is the book of record for funds received and settled. Comparing them directly without knowing which owns what is the source of most reported "mismatches."
• Is "revenue" defined the same way across storefront, ERP, and payment processor? Gross sales, net sales, and net revenue after refunds, chargebacks, payment processor fees, and tax are four different numbers. They should differ — but they should differ predictably.
• Are you comparing gross sales or net sales? A refund issued in the storefront but not yet processed in the ERP will create a temporary gap. A pending refund on the payment processor side will do the same.
• Are you comparing order count, transaction count, or line item count? These three are not interchangeable. One order can contain multiple line items. One transaction can represent multiple orders if they were merged at POS. One payment can cover multiple transactions if they were combined at settlement.

Common trap: Mixing order count with transaction count is one of the most frequent definitional errors in retail integration troubleshooting. A store that processed 40 orders but settled 37 transactions may have had 3 orders voided or merged post-authorization. If you're comparing order count from the storefront against transaction count from the payment processor, the gap is not a bug — it is a definition mismatch.

Check Sync and Integration Job Status (Retail Integration Troubleshooting)

When the time window is correct and the definitions are aligned but numbers are still diverging, the next step in retail integration troubleshooting is to look at the integration layer itself — the jobs, webhooks, and exports that move data between storefront, ERP, and payment processor.

Work through these items:

• Did the last sync between storefront and ERP complete successfully? Most modern stacks run a middleware job on a schedule or trigger-based interval. Check the job status dashboard for your integration middleware — whether that's a native connector, an iPaaS tool, or a custom integration.
• Is there a pending job, a queued webhook, or a failed export in the last 24 hours? A queued but not yet processed webhook will cause the ERP to lag behind the storefront. A failed export will cause it to lag permanently until re-run.
• Check integration logs for any entries during the exact window where numbers diverged. Look for entries with a status other than "completed" or "confirmed." A log entry that shows "sent" but no corresponding "received" confirmation on the ERP side is a sign of a stalled handoff.
• Capture the integration job ID, timestamp, and error message if present. Even a partial error message gives your IT team or integration partner a starting point that cuts hours off troubleshooting time.

For a deeper look at how integration log patterns signal whether a problem is a failed job or a process-level issue, see Retail Reporting and Finance Visibility Troubleshooting: Why Your Storefront, ERP, and Finance Dashboards Show Different Numbers.

Checkpoint: If a failed or stalled integration job is the root cause, the fix is re-running the job or clearing the error — not escalating a data quality issue. Document the job ID and the window it failed, and you have everything needed to resolve it.

Rule Out Pending and Held Transactions (Payment Reporting Mismatch)

When the sync job completed successfully and numbers are still apart, the next most likely source of a false discrepancy in payment reporting mismatch scenarios is transactions in flight — authorizations or refunds that have not yet settled.

Run through these items:

• Are there authorizations that haven't settled yet? Payment processors authorize transactions at the point of sale but settle them on a next-day or multi-day cycle depending on the processor and card type. An authorization that appears in the storefront may not appear in the payment processor's settled transactions for 24–72 hours.
• Are there refunds in "pending" state on either side of the reconciliation? A refund initiated in the storefront but not yet processed by the payment processor will show as a deduction on one side and not the other. The same applies in reverse if the refund was issued directly in the ERP or payment processor portal.
• Do delayed settlement windows explain the gap? If you're running a same-day reconciliation and your payment processor settles on a T+1 or T+2 basis, your settled totals will always be lower than your storefront totals by the amount of unsettled authorizations. This is not a discrepancy — it is a timing difference.
• Pull a transaction-level export, not just summary totals. Summary totals hide pending vs. settled breakdowns. A transaction-level export lets you see which authorizations are still in pending state and which refunds are held rather than processed.

For a detailed walkthrough of how pending refunds specifically create false discrepancies in storefront-to-ERP reconciliation, see Retail Payments and Reconciliation Troubleshooting: The Refund Mismatches Between Storefront and ERP That Signal a System Handoff Problem. For context on how reconciliation timing affects daily finance visibility, see Retail Payments and Reconciliation: The Hidden Cost of Daily Reconciliation Delays.

Checkpoint: List the pending authorization count, the pending refund count, and the dollar amount held. If these figures explain the delta within a reasonable margin, the discrepancy is a settlement timing issue — not a data problem.

Validate Currency, Region, and Tax Settings

Configuration drift is a less common source of dashboard discrepancies but it is worth checking quickly when the items above have ruled out the more likely causes. Small, consistent gaps that survive across multiple reconciliation periods are the signature of a configuration mismatch.

Check these items:

• Are all systems operating in the same currency? If you have a multi-region setup or have recently added a new sales channel, the newly added channel may be operating in a different base currency. Currency conversion differences will produce a persistent, proportional gap.
• Are you comparing like-for-like region rollups in a multi-region setup? If your ERP aggregates by region and your storefront aggregates across regions, the totals will differ if the regions are not aligned in both systems.
• Do tax-included vs. tax-excluded configurations match across systems? Some storefronts report revenue inclusive of tax; others report it exclusive. If your ERP is configured for tax-exclusive reporting and your storefront is configured for tax-inclusive, every transaction will show a small but consistent gap equal to the tax rate applied.
• Tax rounding differences between systems can create visible gaps even when the underlying transactions match. Most systems round to two decimal places, but rounding methods vary. On high-volume days, accumulated rounding differences can produce gaps in the tens to hundreds of dollars.

Checkpoint: If configuration drift is the issue, the delta will typically be proportional and consistent across the reconciliation period rather than concentrated in a single day or transaction batch.

Capture Everything Before You Escalate

If the checklist has ruled out time-window mismatches, definitional differences, failed sync jobs, pending transactions, and configuration drift — and numbers are still diverging — you now have a clean handoff package that makes your escalation productive rather than wasteful.

Prepare these items before contacting IT or opening a support ticket:

• Screenshot each dashboard with the same date range and query timestamp visible. All stakeholders should be looking at the same window, the same cutoff, and the same moment in time.
• Export raw transaction or journal-level data from each system — not just summary views. Summary views hide the detail needed to trace a discrepancy to its source. Journal-level exports allow someone reconstructing the reconciliation to see every line item.
• Note any system changes, updates, or user actions in the last 24–48 hours. Did someone run a manual adjustment in the ERP? Was a new payment processor added? Were tax settings changed? These context items are often the difference between a fast resolution and a long investigation.
• State the specific delta clearly: "Storefront shows $X, ERP shows $Y, delta is $Z for the period [start date] through [end date], queried at [timestamp]."

Checkpoint: You now have a complete reconciliation package: time window documented, definitions confirmed, integration job history noted, transaction-level exports pulled, delta statement written, and system change log attached. This is what a good escalation looks like — and it is what makes IT or your integration partner able to move directly to the root cause rather than spending the first hour reconstructing the context.

When The Delta Checklist Rules Everything Out — What's Next

If the checklist rules out the common causes and numbers are still diverging, the gap is likely in the integration layer itself — the handoff logic between storefront, ERP, payments, and reporting. That is where the disconnect between systems becomes structural rather than operational.

This is the specific problem the Integration Foundation Sprint is designed to solve. TkTurners runs a focused two-week engagement that maps the authoritative source for each metric, identifies where handoff logic is breaking down, and establishes a clean reconciliation baseline that your team can maintain and trust.

If this describes your situation — numbers that won't reconcile, systems that won't talk to each other cleanly, and a delta sheet that keeps growing — book a 30-minute discovery call and bring your delta sheet and integration logs. We'll map the gap and tell you exactly what it would take to close it.

FAQ

Why are my storefront and ERP sales numbers different?

In most omnichannel stacks, the storefront and ERP are not measuring the same thing even when the labels look similar. The storefront is the book of record for orders placed; the ERP is the book of record for inventory and cost of goods. If you're comparing gross sales from the storefront against net revenue from the ERP after refunds, fees, and tax, those are intentionally different outputs. Confirm which system is the authoritative source for each metric before treating a difference as a discrepancy.

How do I check if a sync job failed between my storefront and ERP?

Check the job status dashboard for your integration middleware — the native connector, iPaaS tool, or custom integration that moves data between systems. Look for a job with a status other than "completed" or "confirmed" within your reconciliation window. Then check the integration logs for the same time period: a log entry showing "sent" without a corresponding "received" confirmation on the ERP side signals a stalled handoff. Capture the job ID and timestamp before taking any other action.

Why does my payment processor show a different total than my ERP?

This is a common payment reporting mismatch symptom. The most frequent causes are settlement timing — the payment processor shows settled transactions only, while the ERP may be counting authorizations that haven't cleared yet — and definitional differences in what each system counts as revenue. A T+1 or T+2 settlement window means today's settled processor total will always lag behind today's storefront total by the amount of unsettled authorizations. Pull a transaction-level export from both systems to see the pending vs. settled breakdown.

What information should I have ready before escalating to IT?

Before opening a ticket or contacting IT, prepare: screenshots of each dashboard with the same date range and query timestamp, raw transaction or journal-level exports (not summary totals), notes on any system changes or updates in the last 24–48 hours, and a clear delta statement — "Storefront shows $X, ERP shows $Y, delta is $Z." This package cuts the first hour of any escalation and signals to IT that you've done the first-response work.

How long does it take to reconcile mismatched dashboard numbers?

If a timezone mismatch, a time-window mismatch, or a pending transaction is the cause, operators typically resolve the discrepancy in under 20 minutes once the checklist is run. If a failed sync job is the root cause, re-running the job takes minutes. Configuration drift and actual integration-layer problems take longer and may require IT or an integration partner. The checklist is designed to eliminate the fast-resolution cases before they become escalated tickets.