Lesson 6 of 6
Trusting the numbers
7 min
An analytical app can be fast, beautiful and wrong. Before a figure is used for decisions, or a new report is released, someone has to prove that it calculates what the business thinks it calculates, for the people who will use it. This lesson gives business users and key users a practical way to do that without becoming analytics developers.
Three questions for any figure
- DefinitionWhat exactly is measured: which documents, which date, which currency, which postings included?
- CompletenessDoes the figure include every document it should, for the user who runs it?
- AccuracyDoes it add up to the sum of the underlying documents?
Reconciling against known documents
The most reliable test is to create or pick documents whose values you know, then check that the report reflects them exactly. In Contoso's test client, Priya's team posts a small, controlled set of billing documents for a dedicated test customer and a dedicated period. The custom query for alternator billing must show exactly those values, by customer and month, including tax treatment and currency as specified.
| Check | How | What it catches |
|---|---|---|
| Controlled data | Post documents with known values to a dedicated customer or period; compare the report | Wrong calculations, wrong date logic, missing document types |
| Cross-report agreement | Compare with another trusted source, such as journal entries for the same account and period | Definition differences, included or excluded postings |
| Drill to documents | Drill from a total to line items and sum them | Aggregation errors and unexpected postings |
| Role-based run | Run with a production-like restricted role | Authorization gaps or over-exposure |
| Before and after | Run, post one document, run again | Real-time behavior and correct inclusion of new postings |
Common causes of wrong numbers
- Date logic. Posting date versus document date versus billing date; fiscal versus calendar periods.
- Currency. Document currency versus company code currency; mixed currencies shown without conversion.
- Scope. Statistical postings, reversals or cancelled documents included or excluded.
- Signs. Credits shown as positive; returns not netted.
- Authorizations. The tester has broader access than the real user.
Upgrades and changes
Released views are kept stable, but SAP adds fields and new views over time, and your own configuration changes (a new document type, a new company code) can change what a query includes. Keep a short regression set for each governed query: a controlled data set, the expected results and the role to run them with. Rerun it after each upgrade and after process changes in the area.
- BuildDefine and documentOwner, data source, filters, measures and intended audience written down
- TestReconcileControlled data, cross-report check, drill-down and role-based run
- ReleaseSign off and transportProcess owner approves; query moves through the landscape
- OperateMonitor useOwner answers questions; unused queries are retired
- UpgradeRegressionRerun the controlled checks; compare with expected results
What would you do?
A new Contoso margin query reconciles perfectly to journal entries when Priya runs it, but a regional controller says September looks too low. What should Priya do next?
- Trust a figure only when its definition, completeness and accuracy are proven.
- Reconcile against controlled documents with known values, and cross-check with a trusted source such as journal entries.
- Test with the audience's real roles, not only with broad access.
- Keep a small regression set for each governed query and rerun it after upgrades and process changes.
Check your understanding · not graded
Lesson check
1. What is the most reliable way to test a new analytical query?
2. A query reconciles for the key user but not for a controller. What is the likely cause?
3. Which is a common cause of wrong analytical totals?
4. When should a governed query's regression checks be rerun?