Audit Trail in SAP – Real Scenario:
How SAP Tracks Every Change Across All Modules

On 03-Apr-2025, buyer Pramod Behera creates PO 4500012347 for 200 units of Alloy Steel Rods (Part ASTR-220) from vendor Pooja Metals Ltd at ₹1,800/unit = ₹3,60,000 total. PO is approved by the plant manager. PO header data is saved in EKKO (EBELN = 4500012347) and item data in EKPO. The original approved price ₹1,800 is now legally committed.

On 18-Apr-2025, senior buyer Sujata Sharma opens the PO in ME22N and changes the unit price from ₹1,800 to ₹2,050 citing "market rate revision." This single change immediately creates two records in SAP: a header in CDHDR (change document header: document number, object class EKKO, date 18-Apr-2025, time 14:32:11, user ANITA.SHARMA) and a detail in CDPOS (field NETPR, old value 1800.00, new value 2050.00, table EKPO, PO number 4500012347). The system records this permanently - it cannot be deleted.

The audit manager pulls the change document report. In SE16N on table CDHDR: filter OBJECTCLAS = 'EINKBELEG' (purchasing document), UDATE between 01-Apr-2025 and 31-Mar-2026. Result: 47 change records found across all POs. Join CDHDR to CDPOS on CHANGENR to see exactly which field was changed on each PO. Alternatively, display PO 4500012347 in ME23N and click the "Changes" button (Environment → Document Changes) to see the complete field-level history in a formatted view.

For a bulk extraction of all PO price changes in FY2025, the ABAP team runs a query joining CDHDR (filter: OBJECTCLAS = 'EINKBELEG', FNAME = 'NETPR') with CDPOS. The query returns: PO number, line item, change date, changing user, old price, new price, and delta amount. 47 PO price changes identified. Of these, 12 were changed without a fresh approval workflow - flagged as a control deficiency in the audit report. Root cause: approval workflow was not configured to re-trigger on price changes.

Based on the audit finding, the SAP BASIS / workflow team configures the approval workflow (transaction SWI2_ADM1) to re-trigger the approval chain whenever the NETPR (net price) field in EKPO increases by more than 5% after initial approval. Change is transported to production. Going forward, any price change exceeding the threshold requires fresh manager approval before the PO can be saved - and the CDHDR/CDPOS trail will show both the change attempt and the approval response, giving auditors complete end-to-end visibility.

The auditor opens FBL3N for G/L account 198000 (Inter-Company Transfers) for company code NTM1, period October 2024. The report reads BSIS (open items) and BSAS (cleared items) joined to BKPF on BUKRS + BELNR + GJAHR. Results show 14 postings totalling ₹4.2 crore. Key BKPF fields: BLART (document type), USNAM (posting user), CPUDT (entry date), CPUTM (entry time), TCODE (transaction code used). Three entries show document type AB (accounting document) posted at 11:45 PM by user SYSADMIN - immediately suspicious.

The auditor double-clicks on suspicious document 1900000445 in FBL3N to open it in FB03. Every field in BKPF is visible: document date 31-Oct-2024, posting date 31-Oct-2024, entry time 23:47:32, user SYSADMIN, reference text "Month-end provision", transaction code FB01. The line items in BSEG show: ₹1.8 crore debit to account 198000 (Inter-Company), ₹1.8 crore credit to account 400000 (Sales Revenue). Crediting sales revenue via a late-night manual journal entry is a major red flag. The document is permanently visible - it cannot be hidden or deleted.

A properly controlled FI document should first be parked (saved incompletely for approval) before being posted. The auditor checks whether document 1900000445 was ever parked and approved. Table VBKPF stores parked document headers. Result: no parked document exists with matching reference - meaning this ₹1.8 crore journal entry was posted directly using FB01 without any parking or dual approval workflow. This is a second control failure that supports the SEBI query findings.

The security team runs the SM20 security audit log to check all activities performed by user SYSADMIN on 31-Oct-2024. SM20 shows every transaction executed, every authorisation check, and every logon/logoff event. Result: SYSADMIN logged in at 23:41, executed FB01 three times (posting ₹1.8Cr, ₹0.9Cr, ₹1.5Cr to account 198000), and logged off at 23:58. Total suspicious posting in 17 minutes: ₹4.2 crore. The SM20 log proves the exact sequence of events and is admissible as digital evidence.

The CFO decides the three documents must be reversed after SEBI review. The auditor uses FB08 to reverse each document with reversal reason 01 (Reversal in current period). SAP creates three new mirror-image documents - same amounts, opposite signs - permanently clearing the incorrect entries. Both the original document and its reversal remain in BKPF/BSEG forever with clear cross-references. The FI audit trail now shows: original posting by SYSADMIN at 23:47 + reversal authorised by CFO at 09:15 on 05-Nov-2024. The complete story is permanently on record.

The compliance manager opens MB56 (Batch Where-Used List) and enters batch number B-API-2025-0301 for material API-PARA-500. MB56 reads MSEG filtered by MSEG.CHARG = 'B-API-2025-0301' and traces every goods movement involving this batch. Result: 2 GRs found - 15-Mar-2025 (500 kg received against PO 4500009876, movement 101) and 22-Mar-2025 (200 kg received against PO 4500009901, movement 101). Total received: 700 kg of potentially contaminated API. Both material documents permanently recorded in MKPF (header) and MSEG (items).

The compliance team checks whether QM inspected this batch on arrival. QA32 shows inspection lot 1000045 was created on 15-Mar-2025 for batch B-API-2025-0301 (origin 01 - incoming inspection). Usage Decision = ACCEPTED on 17-Mar-2025 by user QA.SURESH. The acceptance allowed the batch into unrestricted stock. Table QALS (inspection lot header: MATNR, CHARG, PRUEFDAT) and QAVE (test results: all parameters passed). The QM audit trail is complete - showing who released the batch and based on what test values.

MB56 continues tracing: batch B-API-2025-0301 was issued to production orders PO-800345 (18-Mar, 300 kg, mvt 261), PO-800367 (24-Mar, 250 kg, mvt 261), and PO-800389 (28-Mar, 100 kg, mvt 261). Total issued to production: 650 kg. Each GI created a material document in MSEG (BWART = 261). The 50 kg remaining in stock is identified via MMBE (still shows 50 kg in quality batch B-API-2025-0301 in storage location QC-HOLD). The three production orders produced finished good batches FG-20250320, FG-20250326, and FG-20250402 - all must be quarantined.

MB56 extended to finished goods: batch FG-20250320 - 10,000 tablets despatched to hospital customer HOSP-Chennai-07 via delivery 80001234 on 25-Mar-2025. Batch FG-20250326 - 8,000 tablets in warehouse (not yet despatched, can be recalled immediately). Batch FG-20250402 - 12,000 tablets despatched to HOSP-Bengaluru-03 on 05-Apr-2025. Sales delivery documents in LIKP/LIPS with confirmed GI in MKPF/MSEG. Two hospitals must be notified for product recall. The complete forward trace from raw material GR to customer delivery is done in under 30 minutes using SAP audit trail.

The compliance manager blocks the remaining 50 kg of batch B-API-2025-0301 using MIGO (movement type 344 - transfer to blocked stock). FG-20250326 (8,000 tablets in warehouse) is blocked using a Quality notification (QM02) setting batch status = BLOCKED in the batch master (table MCH1: ZUSTD = blocked). A formal Q2 vendor complaint notification (QM01) is raised against the API supplier with the recall details, test evidence, and corrective action request. All actions permanently recorded in SAP - complete regulatory dossier ready for FDA/CDSCO inspection within 4 hours of the recall trigger.

The HR compliance officer opens PA20 (Display HR Master Data) for the three employees flagged by the whistleblower - personnel numbers E-10234, E-10289, E-10312. For Infotype 0008 (Basic Pay), all historical records are displayed - SAP shows every single salary change since the employee's hire date, with BEGDA (effective date), ENDDA (end date), BSGRD (pay grade), LGART (wage type), and BETRG (amount). Employee E-10234 shows three salary changes in FY2025 - unusual. Standard practice is one annual revision in April. The two additional changes (July and November) are immediately suspicious.

PA03 (Display Change Documents for an Employee) shows the complete audit log for a specific personnel number. For PERNR E-10234, Infotype 0008: Change 1 (01-Apr-2025, ₹45,000→₹52,000, user HR.RAMAIAH - legitimate annual increase, approved in PA40 action). Change 2 (15-Jul-2025, ₹52,000→₹63,000, user HR.NAGESWARA - no corresponding PA40 action found, no manager approval workflow triggered). Change 3 (01-Nov-2025, ₹63,000→₹71,000, user HR.NAGESWARA - same user, no approval). CDHDR for OBJECTCLAS = 'PERSDATA', OBJECTID = 'E-10234' confirms same user, same 11:30 PM time pattern for both changes.

To confirm the salary increases were actually paid (not just data-entered but not processed), the compliance officer checks payroll results for periods July–November 2025 using PC_PAYRESULT. Payroll cluster table PCL2 shows wage type M010 (basic pay) with the increased amounts in the July and November payroll runs for E-10234. The unauthorised salary increases of ₹11,000 and ₹8,000 per month were processed and paid - actual financial loss to the company from mid-July to December = ₹19,000 × 5.5 months = ₹1,04,500. This amount is now a quantified audit finding for the board report.

The security team runs SUIM (User Information System) to check whether HR.NAGESWARA's authorisation profile allowed changes to Infotype 0008 without workflow approval. Result: the user had authorisation object P_ORGINCON with access to Infotype 0008 for all personnel areas - a segregation of duties failure. The user should only have READ access to salary infotypes, not WRITE access without approval workflow. SU53 confirms the exact authorisation objects used during the salary change postings. SAP security remediation: remove P_ORGINCON write access from all payroll data entry users and mandate workflow approval for IT 0008 changes.

The auditor opens FK03 (Display Vendor) for vendor V-00456 and navigates to Payment Transactions tab - the current bank account shows account 9876543210 at a private bank. The original account registered during vendor onboarding was 1234567890 at State Bank. Change Document query: SE16N on CDHDR with OBJECTCLAS = 'KRED' (vendor master), OBJECTID = '0000V-00456'. Result: one change record found, date 04-Jun-2025 at 22:15, user AP.TRAINEE01. CDPOS shows field BANKN (bank account number) changed from 1234567890 to 9876543210. A trainee user changed a vendor bank account at 10 PM three days before a ₹48 lakh payment run - clear fraud pattern.

The auditor opens FBL1N for vendor V-00456 and finds payment document 2500008901 dated 07-Jun-2025 for ₹48,02,400. FB03 on this document shows: posted by F110 (automatic payment), bank HDFC, house bank main account, cleared against 4 open invoices. BKPF.USNAM = F110 (system), BKPF.TCODE = F110. The payment run (LAUFD = 07-Jun-2025) details are in table REGUH (payment run header: bank, payment method, amount) and REGUP (payment items: vendor, invoice, clearing document). The bank transfer file was sent to HDFC on 07-Jun - the fraudulent account number was on the NEFT file.

SM20 Security Audit Log for user AP.TRAINEE01 on 04-Jun-2025: logged in at 22:08, executed FK02 at 22:14, changed bank account of V-00456 at 22:15, logged off at 22:19. No other activity. The user's access log shows this was their first ever FK02 execution - they had never accessed FK02 before. SUIM shows AP.TRAINEE01 was assigned authorisation profile SAP_ALL (full system access) - a catastrophic access control failure. A trainee with SAP_ALL can change any master data in the entire system without restriction or oversight.

Post-incident, the SAP security team configures Dual Control for Vendor Master via SPRO → FI → AP → Vendor Accounts → Master Data → Define Sensitive Fields for Dual Control. Field BANKN (bank account) and BANKL (bank key) are added as sensitive fields. Now, when any user changes the bank account of a vendor in FK02, the record is saved in a pending/unconfirmed state - the change does NOT become active until a second authorised user confirms it in FK08 (Confirm Vendor Changes). Table VBKNA stores the pending change. This single configuration change would have prevented the entire fraud.

Inspection Lot IL-2025-0401 for API batch B-API-0401 arrives. QA analyst Dr. Priya Nair opens QA32 to record results. For each characteristic (Assay 99.3%, Moisture 0.08%, Heavy Metals ND, Microbial Count within spec), Dr. Priya enters the measured values. On saving the results, SAP displays the Digital Signature dialog: "Please authenticate - User ID: [priya.nair] Password: [****] Reason: [Results entered from laboratory notebook LNB-2025-041 page 34]." The signature is saved in the DRAD (digital signature log) table with timestamp 09:23:14, user priya.nair, transaction QA32, and the reason text. This meets 21 CFR Part 11 Section 11.50 (signature manifestation).

After reviewing all results, QA Supervisor Mr. Arjun Mehta makes the Usage Decision in QA11 for IL-2025-0401: UD Code A (Accept). SAP requires a second digital signature here since the Usage Decision is a GMP-critical action configured for dual-role authentication. Signature 1: arjun.mehta enters password + reason "All results within specification, batch released for production." Signature 2: QA Manager dr.sridhar also authenticates: "Reviewed and independently verified - Release approved." Both signatures recorded in DRAD with timestamps. The batch moves to unrestricted stock via movement 321. The UD cannot be changed once signed - only reversed with a new, separately signed UD.

During tablet compression, 16 inspection points are recorded every 30 minutes (weight, hardness, disintegration, friability). Each inspection point save in QA32 requires a digital signature from the production analyst present at the machine. Each of the 16 signatures is logged in DRAD: user ID, exact time, machine ID in reason text, and the measured values in QAVE. The FDA investigator can see that every 30-minute measurement was signed by a physically present analyst - there are no retroactive entries (CPUDT = actual measurement time, not hours later). This demonstrates real-time data integrity under 21 CFR Part 11 Section 11.10(e) (audit trail for GMP records).

The QA manager generates the complete Electronic Batch Record for Batch QA-INSULIN-2025-0412 using custom batch record report QGA4 (or a smartform built on QALS + QAVE + DRAD + MKPF). The report shows: all incoming material QM results with analyst signatures, all in-process inspection point data with operator signatures, finished product release results with QA manager dual signatures, batch disposition (UD = Accept, released 22-Apr-2025 14:45), and equipment calibration status at time of manufacture. The FDA investigator reviews the 47-page electronic batch record - all entries are time-stamped, user-attributed, and unchangeable. Zero observations on data integrity. Facility approved.