Lesson 4 of 6
Error handling and monitoring
10 min
Listen to this lesson
In a running Central Finance landscape, documents fail every day: a new G/L account without a mapping, a cost center locked in the central system, a period closed centrally but open in the source. The question is not whether errors happen but whether someone sees them, fixes them and reposts them before the close. That is an operating model, and it must be tested like one.
Where errors appear
| Layer | Where to look | Typical errors |
|---|---|---|
| Replication | SLT monitoring (cockpit transaction LTRC in the SLT system) | Connection failures, blocked or slow queues |
| Posting in the central system | AIF monitor, /AIF/IFMON and /AIF/ERR, namespace /FINCF | Missing mappings, closed periods, locked objects, derivation errors |
| Initial load reposting | Application log reached from the initial load activities in CFINIMG | Errors from reposting FI initial load data |
| Business result | Reconciliation reports and close checklists | Documents posted but with wrong values |
Where Central Finance errors surface. Verify transactions for your release.
AIF is the heart of daily operations. Each failed document is a message with a status, an error text and the data that arrived. A user registered as a recipient for the Central Finance namespace sees the messages, corrects the cause (adds the mapping, opens the period, unlocks the object) and restarts the message, which posts the document. Out of the box, messages go to one recipient; routing errors to different teams by company code or error type needs extra setup. AIF can also reprocess some errors automatically on a schedule, which is useful for temporary causes such as locks.
An operating model for errors
- DetectAIF alerts and a daily dashboard per source and company code
- RouteMapping errors to master data, period errors to the close team, technical errors to Basis
- FixCorrect the cause in the central system or the source, never by changing the message data casually
- RestartRepost from AIF and confirm the document posted
- ReportOpen errors by age at every period end; zero unexplained errors before close
Two rules from the what-if design are worth copying. First, the central close cannot start while AIF holds errors for the period, unless finance accepts them in writing with an amount. Second, editing message data in AIF to force a posting is restricted to named users and logged, because it changes what the central ledger says without changing the source.
What would you do?
Two days before month-end close, the AIF monitor shows 1,240 errors for company code 1710, all "G/L account not mapped" for one new account created in EP1 last week. What is the best response?
What goes wrong in testing
| Gap | Effect | Test |
|---|---|---|
| Only happy-path documents tested | Error handling is first exercised in production | Inject known errors: unmapped account, closed period, locked cost center |
| No recipient setup in QAS | Errors pile up unseen | Check every error reaches a named team |
| Restart not tested after fix | Fixed causes still leave unposted documents | Restart and confirm the posted document and its values |
| Error volume untested | Thousands of errors overwhelm the team | Test bulk restart with a realistic error volume |
Error handling tests that are often skipped.
Measures worth watching
| Measure | Why it matters | Illustrative target |
|---|---|---|
| Replication latency at peak | Late documents distort daily cash and close reports | Minutes, not hours, during month-end |
| Open AIF errors by age | Old errors become close blockers | Nothing older than two working days |
| Errors per 1,000 documents by source | Shows where mapping governance is weak | Falling after each release |
| Restarts that fail again | Fixes that did not address the cause | Close to zero |
Operational measures for Central Finance error handling. Set your own targets with finance.
These measures become the run team's dashboard after go-live and the test team's exit criteria before it. If the final test cycle shows errors piling up faster than the team can clear them, the operating model is not ready, regardless of how many test cases passed.
Who may do what
Error handling needs authorizations that are easy to get wrong. Nadia, Contoso's security and GRC lead, reviewed the what-if role design and made three rules: AIF recipients can view and restart messages for their own company codes; canceling a message needs a second person; editing message data is a firefighter-style privilege with a log reviewed weekly. These rules belong in the test plan too: a tester tries to cancel without approval and expects to be stopped.
| Role | Can do | Cannot do |
|---|---|---|
| AIF recipient, 1710 finance | View, analyze and restart 1710 messages | Cancel or edit messages; see other company codes |
| Master data team | Create key and value mappings | Restart or cancel messages |
| Close lead | Approve cancellations with amount and reason | Edit message data |
| Emergency user | Edit message data under a logged session | Act without a ticket and review |
An illustrative role split for Central Finance error handling.
- SLT monitoring covers replication; AIF covers posting errors in the central system.
- Fix the cause, then restart the message; restrict editing message data.
- Route errors by type and set a zero-unexplained-errors rule before the close.
- Inject errors in testing so error handling is proven before production.
Check your understanding · not graded
Lesson check
1. Where are posting errors in the central system handled?
2. What should happen after the cause of an AIF error is fixed?
3. Why restrict editing message data in AIF?
4. Which test proves error handling before production?