Lesson 4 of 5
Verifying reports independently
12 min
Listen to this lesson
The most common way to "test" a financial report is to run it and see that it produces numbers. The second most common is to compare it with another SAP report. Neither proves much. If the configuration that drives both is wrong, both reports agree and both are wrong. To test a report you need an independent expectation: a value calculated outside the system under test, from the source data, that the report must match.
Building the expected values
Start from your controlled test transactions. For each scenario in the mock close period you know the inputs: quantities, prices, standard costs, tax rates, exchange rates, depreciation terms. From those you can calculate, in a spreadsheet, the expected journal entries and then the expected account balances. This is an expected trial balance for the test transactions.
| Scenario (Contoso, company code 1710) | Calculation | Expected effect (USD) |
|---|---|---|
| Sell 50 CMC-ALT-100 at 250.00 to Great Lakes Fleet Services | 50 × 250.00 | Revenue 12,500.00; receivable 12,500.00 (before tax) |
| Goods issue of 50 CMC-ALT-100 from plant 1710 | 50 × standard cost 150.00 | Cost of goods sold 7,500.00; inventory -7,500.00 |
| Receive 500 CMC-RTR-200 from Lakeside Components at 40.00 | 500 × 40.00 | Inventory 20,000.00; GR/IR -20,000.00 |
| Depreciation of a 120,000.00 machine, 10 years straight line | 120,000.00 ÷ 120 months | Depreciation expense 1,000.00; accumulated depreciation -1,000.00 |
| Gross margin on the sale | 12,500.00 - 7,500.00 | 5,000.00 |
Independent expected values calculated from test inputs. Prices other than standard cost are fictional.
- InputsTest transactions with known quantities, prices, rates and terms
- Expected entriesSpreadsheet calculates the journal entries each scenario should post
- Expected balancesEntries summed per account, segment and profit center
- Run reportsTrial balance, balance sheet and P&L for the period
- CompareDifferences listed and explained to the cent, or logged as defects
Balance sheet and P&L checks
- The trial balance balances. Total debits equal total credits for company code 1710, and for each segment if document splitting is active.
- Every account is mapped. The financial statement version assigns each G/L account to a node. Accounts that are not assigned typically show up in a separate unassigned node; that node should be empty.
- Balance sheet equation. Assets equal liabilities plus equity, with the period's profit or loss included.
- P&L ties to the balance sheet. The net result on the P&L equals the result shown in equity for the period.
- Signs and presentation. Revenue and liabilities appear with the sign convention your reporting expects; contra accounts net correctly.
- Comparative columns. Prior period and prior year columns show the right periods and, after migration, the migrated balances.
In the Fiori launchpad, finance users typically use apps such as Trial Balance and the balance sheet and income statement apps, alongside SAP GUI reports. Use the apps your users will use at close, because each has its own filters, hierarchy and currency settings that can be configured wrongly.
Check the dimensions as well as the totals. In SAP S/4HANA, each journal entry line carries profit center, segment, functional area and, for margin analysis, market attributes such as customer and product. A P&L by profit center can be wrong even when the company code total is right, for example when cost of goods sold for CMC-ALT-100 lands on a default profit center. Include at least one expected value per reporting dimension your management reports use.
Using production-like data
Controlled test transactions prove the rules. A mock close on a scrambled production copy or migrated data proves volume and variety. For that data you cannot calculate every value, so use reasonableness checks instead: compare with the legacy system's reports for the same period, check key ratios, and drill into the largest movements. Both approaches belong in the plan.
| Controlled test transactions | Production-like data | |
|---|---|---|
| Proves | Accounting rules and configuration | Volume, variety and real-world edge cases |
| Expected values | Calculated to the cent from inputs | Reasonableness: legacy reports, key ratios |
| Typical check | Expected trial balance matches report | Largest movements drilled into and explained |
| Weakness | Limited variety | Cannot calculate every value |
What would you do?
A tester validates the new balance sheet by comparing it with the trial balance from the same QAS system. They agree, so the tester marks the report passed. What is wrong with this approach?
- Comparing a report to another report from the same system proves little.
- Build an expected trial balance from test inputs and agreed accounting rules.
- Check balancing, mapping completeness, the balance sheet equation, P&L to equity and comparatives.
- Use reasonableness checks against legacy reports for production-like data.
Check your understanding · not graded
Lesson check
1. Why must report verification use independently derived expected values?
2. Contoso sells 50 alternators with standard cost 150.00. What is the expected cost of goods sold?
3. A new G/L account appears in the unassigned node of the financial statement version. What does that mean?
4. What is the right check for a mock close run on large production-like data?