A green SAP BW load does not prove that a business report is correct. The load may have completed technically while the report uses a different date, status, sign convention or aggregation rule. Reconciliation starts by defining the same business population on both sides, then tracing where the results diverge.
This tutorial is a practical companion to SAP BW/BI training in Vizag. It focuses on a report-total investigation, complementing the existing guides to data modelling, extraction and process chains.
Define exactly what the total means
Before comparing numbers, write down the report definition. “September sales” is incomplete: it could mean order value, billing value, posted revenue or cash received. Those measures come from different events and do not have to match.
Agree on the business measure, relevant document date, company or sales organisation, status filters, currency, unit and credit-note treatment. Record the cutoff time and whether the source data can still change. A report refreshed before a late source posting cannot be reconciled to an unrestricted live total without accounting for that difference.
Also identify the grain: what does one row represent? A document header, billing item and daily summary have different levels of detail. Row counts only become comparable when their meanings are aligned.
Worked example: ₹2,300 or ₹2,800?
The following fictional teaching dataset uses simple status labels, not actual SAP table fields or status codes. All amounts are INR and exclude tax. Define the measure as posted September net sales, with credit notes represented as negative amounts.
| Record | Status | Net amount | Included? |
|---|---|---|---|
| Invoice A | Posted | ₹1,000 | Yes |
| Invoice B | Posted | ₹1,500 | Yes |
| Credit note C | Posted | −₹200 | Yes |
| Invoice D | Draft | ₹500 | No |
The expected total is ₹1,000 + ₹1,500 − ₹200 = ₹2,300. A raw sum of all four records is ₹2,800. The ₹500 difference is caused by population selection, not necessarily by missing data or an unsuccessful load.
If a transformation changes the credit note from −₹200 to +₹200, the three posted records total ₹2,700. That produces a ₹400 difference because the same ₹200 has moved from subtracting to adding. These are two separate hypotheses that can be checked against record-level evidence.
Compare each stage of the source-to-report path
A reconciliation sheet should show the object, request or refresh reference, applied filters, record grain and business total at each stage. The appropriate objects and persistence layers depend on the BW release and model.
| Stage | Evidence to compare | Possible explanation |
|---|---|---|
| Source selection | Eligible business records and agreed cutoff | Wrong date, status or organisation filter |
| Extraction | Selected fields and records for the relevant request | Extraction filter, late record or missing delta |
| Transformation | Mapped fields, derived values and signed amounts | Sign conversion, lookup or mapping error |
| Reporting provider | Available data, key relationships and aggregation | Duplicate join matches or unsuitable grain |
| Query | Variables, restrictions, formulas and currency settings | Different measure or selection definition |
| Workbook | Refresh state and displayed selections | Old results or a changed filter |
Use the DataSources, transformations and DTPs guide to understand the responsibilities of the load objects. A DTP completion message alone does not tell you whether a mapped business field has the intended value.
A repeatable investigation checklist
- Reproduce the report. Capture the query, variable selections, measure, user context and refresh time. Save the original result before changing anything.
- Align the source comparison. Use the same business definition and cutoff. Separate genuine missing records from records intentionally excluded by the measure.
- Trace a small set of keys. Follow Invoice A, Invoice B and Credit note C through the model. Inspect values as well as counts.
- Check signs, currency and units. Compare amounts on a common basis. Do not add unlike currencies or compare translated values with untranslated ones.
- Inspect the model relationships. Confirm that a join does not match multiple text, validity or lookup rows for one business record.
- Inspect query calculations. Check restricted key figures, calculated key figures, aggregation and exception aggregation where relevant. A ratio or balance may not behave like a simple additive amount.
- Explain authorisation differences. Compare results within approved access. Different permitted populations may produce different totals; broader access is not automatically the correct business view.
- Verify the correction. Re-run the same selections and record both the corrected total and record-level evidence.
What if the record counts match?
Matching counts can hide incorrect signs, wrong customer assignments or compensating errors. In the example, three correctly selected posted records still give the wrong total if the credit note is mapped with the wrong sign. Counts are a diagnostic check, not proof of business correctness.
Equally, a source can have more rows than the target because the target legitimately aggregates the data. Define the aggregation and compare the appropriate totals and keys instead of requiring every layer to have an identical count. The SAP BW data-modelling guide explains why grain and join cardinality matter.
Do not use a reload as the first diagnosis
Before reprocessing, understand the load mode, delta handling and target update behaviour. Repeating a load can be harmless in one design and introduce duplicate or inconsistent results in another. Identify the failed condition, affected records and approved recovery path first.
Record what the recovery is expected to change. Afterward, check the business total and the relevant request history. If the load succeeded but the query definition was wrong, a reload may add work without correcting the report.
Turn the example into a portfolio exercise
Create a reconciliation workbook with five sections: business definition, source records, stage-by-stage totals, discrepancy explanation and retest evidence. Start with the ₹2,300 baseline. Test including the draft invoice, reversing the credit-note sign and applying a mismatched date filter one at a time.
Label every dataset and screenshot as a training exercise. In an interview, explain which hypothesis you checked, where the first divergence appeared and what evidence supports the correction. Connect the output with the BW queries and Analysis for Office guide.
Learn SAP BW/BI through source-to-report practice
Softenant’s SAP BW/BI course in Visakhapatnam covers data flow, transformations, DTPs, queries and validation scenarios. Review the course page and ask which BW version, reporting tools and practice-access arrangements apply to the current batch.