Testing reports against the source

A dashboard is only useful if its numbers match the system of record. This lesson gives a repeatable method for testing SAC stories and models against SAP S/4HANA, for live and import models, and the evidence a tester keeps. It applies the reconciliation ideas of sap-dap-301 at the report level.

The method

1. Fix the scope: a closed period (September 2026), company codes 1710 and 1810, ledger 0L.
2. Pick the reference: for live models, the same analytical query run in a Fiori multidimensional report; for import models, the source query or table filtered to the import's cut-off; for finance totals, the journal (for example the trial balance or the revenue accounts).
3. Reconcile totals by dimension: each KPI by company code, profit center and month, story versus reference.
4. Run known cases: invoice 90001877 for Great Lakes Fleet Services (12,000.00 revenue, 7,500.00 COGS, 4,500.00 margin), a Chicago sale at 156.00 standard, a credit memo of 2 pieces (-480.00 revenue).
5. Test settings: filters cleared and set, version selection, scale, currency labels, unbooked members.
6. Test access: a user restricted to company code 1710 sees no 1810 values, in the story and through the Excel add-in.
7. Record evidence: screenshots are not enough; export the story table and the reference with filters, timestamp and user.

Live and import differences

For live models, the story and the Fiori report run the same query, so differences usually come from variables, story filters or different users' authorizations. Test the same user in both. For import models, differences come from the import itself: job timing, field mapping, transformations, or rows rejected during import. Record the import job's run time and row count, and compare against the source with the same cut-off.

Most of these checks can be stored and rerun. Keep the reference queries, the known-case document list and the expected values with the test case in SAP Cloud ALM, and export story tables with their filters as evidence. When SAP releases a new SAC version, rerun the stored set on the closed period and compare with the baseline; any difference is either explained by the release notes or a defect. The same set becomes the regression suite when Noor’s team changes the model, so a new measure or dimension never silently changes an existing figure.

Common false alarms

• Different users: the tester’s restricted role versus the developer’s full access.
• Different times: an import model as of 02:00 versus a live query at 10:00.
• Different definitions: revenue including freight in one report and excluding it in the other.
• Different scale: thousands in the story, units in the Fiori app.
• Different currency or rate type: month-end versus average rates for translated values.

Rule each of these out, in this order, before raising a defect. A defect log full of false alarms costs the BI team time and the test team credibility.