Lesson 5 of 5
Testing master data changes
7 min
A new G/L account looks like a small change. In practice it touches posting rules, controlling, reporting, interfaces and sometimes automatic account determination. When it is wrong, the symptoms show up weeks later in the wrong place: a "not assigned" line, a cost center report missing costs, a clearing account that cannot be cleared. Testing a master data change end to end, before release, is cheap insurance.
An end-to-end test for a new account
- Review the master dataDisplay chart, company code and controlling area data; compare with the approved request
- Post a positive testPost a journal entry to the account in the test client with realistic data
- Check required fieldsConfirm the fields the field status group should require are required
- Check controllingFor cost accounts, confirm the cost center or other object is required and the cost appears in its report
- Check reportingConfirm the balance appears on the right line in every FSV and not under "not assigned"
- Run negative testsTry what must fail: posting without a cost center, a manual posting to a post-automatically-only account
- Record evidenceJournal entry numbers, report extracts, error messages, approver
Negative tests matter as much as positive ones
A positive test proves the account works. A negative test proves the controls work. Both are needed for sign-off. For G/L master data, the most useful negative tests are short and specific.
| Control | Negative test | Expected result |
|---|---|---|
| Primary cost account needs an assignment | Post to the account without a cost center | Posting blocked with a message asking for an account assignment |
| Reconciliation account | Enter the account as a normal G/L line | Posting blocked; must post via customer, supplier or asset |
| Post automatically only | Post a manual journal entry to an inventory account | Posting blocked |
| Required field from field status | Leave the required field empty | Posting blocked until the field is filled |
| Tax category | Post with a tax code the account does not allow | Error on the tax code |
Negative tests for G/L account controls.
Changing an existing account
Changes to accounts that already have postings need more care than new accounts, because they affect history and running processes. Changing a field status group can make a field required that interfaces do not send, so the next automatic posting fails. Blocking an account for posting stops any process whose account determination still points to it. Changing an FSV assignment moves past balances between report lines. For each change, ask which processes post to the account (check line items for the last few months by journal entry type), and run a regression posting for each of those routes, not just a manual journal entry.
Use realistic test data. A test posting of 1 USD to a cost center nobody uses proves little. Post a realistic amount with the cost center, profit center and tax code a real user would use, so the controlling and reporting checks are meaningful.
How the change reaches production
Companies move G/L master data to production in different ways: maintained manually in each system, uploaded in bulk, or distributed by a replication process. Whatever the route, test it. The most common go-live surprise is an account that was perfect in the test client and was created slightly differently in production. A simple comparison of the master data display in both systems, field by field, closes that gap.
- Day 1Request approvedAccount purpose, type, company codes, FSV node and owner agreed with Dan.
- Day 2Built in testMaster data created in client 100 in QAS by the master data team.
- Day 3TestedPositive and negative tests run by a finance key user; evidence recorded.
- Day 4ApprovedDan reviews the evidence and approves release.
- Day 5Created in productionSame values maintained in production; field-by-field comparison with test.
What would you do?
Priya's team tested a new revenue account in QAS: postings worked and the FSV line was right. After go-live of the change, revenue postings to the account from billing fail in production. What is the most likely gap?
- Test a new account end to end: master data, posting, required fields, controlling, reporting.
- Negative tests prove the controls; they are part of sign-off.
- Test the real posting route, including automatic account determination where it applies.
- Compare production master data with test before the account is used.
- Keep evidence: master data display, journal entry numbers, report extracts, blocked postings.
Check your understanding · not graded
Lesson check
1. Which is a negative test for a primary cost account?
2. Why test the automatic posting route for a revenue account?
3. What should be compared before using a new account in production?
4. Which evidence supports sign-off of a new G/L account?