SAP S/4HANA Financial Accounting: Process Architecture, Universal Journal Integration, and Governance Controls

作者：Sajiv Francis 约 44 分钟阅读更新日期：2026-07-22 标签：云架构, Cloud Architecture, 架构, SAP, S/4HANA, FI, CO, 财务

Executive Summary

Financial accounting in SAP S/4HANA is not a back-office function bolted onto the end of business operations — it is the connective tissue of the entire value chain. Every material business event, whether a sale, a procurement, a goods movement, a payroll run, or an asset acquisition, generates a financial accounting touchpoint. The quality of financial reporting is therefore a direct function of the quality of upstream process design.

SAP S/4HANA represents a fundamental architectural shift from its predecessor ECC. The introduction of the Universal Journal (table ACDOCA) collapses what were previously five separate data stores — FI line items, CO line items, Asset Accounting, Material Ledger, and Profitability Analysis — into a single, real-time line-item table. This is not an incremental improvement; it is a restructuring of how financial truth is produced and consumed inside an enterprise.

The practical consequences are significant:

Reconciliation becomes structural, not periodic. Subledgers (AR, AP, AA) post in real time to ACDOCA. The period-end reconciliation check is a verification step, not a correction exercise.
Management accounting is no longer a downstream consumer of FI data. Cost center, profit center, and profitability attributes are captured at the moment of transaction posting — not allocated in batch at month-end.
Reporting is on-demand from live transaction data. Financial statements, audit journals, and profitability reports all read from the same source. There is no separate aggregation layer, no extract, no reconciliation between FI and CO reporting.
Audit trails are complete and traceable by design. The Audit Journal (Fiori app F0997) and Compact Document Journal (S_ALR_87012289) provide full line-item traceability from any reported figure back to the originating business event.

The four core financial accounting processes — Order-to-Cash, Purchase-to-Pay, Acquire-to-Retire, and Record-to-Report — each correspond to a primary subledger (AR, AP, AA, GL respectively) and converge in the Universal Journal as their common integration point. The period-end close sequence enforces a strict dependency: subledger completeness gates the GL close, which gates the CO allocation runs, which gate external financial reporting.

For finance leadership, the strategic implication is clear: S/4HANA shifts the governance burden upstream. Controls that previously caught errors at period-end — mispostings, unmatched invoices, misclassified assets — must now be embedded in the originating business processes. Accounting’s role evolves from repair shop to process co-determination authority.

Context: Organizational Architecture & Value Chain

Organizational Foundation

Financial accounting in S/4HANA is built on a layered organizational structure that underpins every process. The key principle is that almost all business transactions have touchpoints to financial accounting, but the majority of postings no longer originate in accounting itself — they flow in from upstream process steps. This makes accounting critically dependent on upstream data quality. Poorly configured upstream processes turn the FI module into a repair shop, a dynamic that any S/4HANA implementation must architect against from the outset.

SAP structures the company value chain across four phases — Design → Build → Sell → Support — with financial accounting as the cross-cutting support process integrated throughout.

Core Process Architecture

Core Process	Scope	Primary FI Area
Order-to-Cash	Presales → Cash collection	Accounts Receivable
Purchase-to-Pay	Supplier selection → Outgoing payment	Accounts Payable
Acquire-to-Retire	Asset lifecycle management	Fixed Asset Accounting
Record-to-Report	Journal entry → Legal & mgmt reporting	General Ledger
Build-to-Stock	Production → Material Ledger	General Ledger
Hire-to-Retire	HR & Payroll	Payroll Accounting
Idea-to-Market	Innovation	Project Accounting / Intangibles
Plan-to-Perform	Financial planning	Accounting as baseline & comparator

Component Relationship Map

flowchart TD
    classDef business fill:#fff3b0,stroke:#cc9a06
    classDef application fill:#b8d4f0,stroke:#1565c0
    classDef integration fill:#e8f5e9,stroke:#2e7d32
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a

    subgraph CORE["Core Business Processes"]
        OTC["Order-to-Cash"]
        PTP["Purchase-to-Pay"]
        ATR["Acquire-to-Retire"]
        RTR["Record-to-Report"]
        BTS["Build-to-Stock"]
        HTR["Hire-to-Retire"]
    end

    subgraph FI["Financial Accounting Subledgers"]
        GL["General Ledger<br>(FI-GL)"]
        AP["Accounts Payable<br>(FI-AP)"]
        AR["Accounts Receivable<br>(FI-AR)"]
        AA["Fixed Asset Accounting<br>(FI-AA)"]
    end

    subgraph CO["Management Accounting"]
        CCA["Cost Center Accounting"]
        PCA["Profit Center Accounting"]
        PA["Profitability Analysis"]
    end

    subgraph RPT["Reporting Layer"]
        FS["Financial Statements"]
        AJ["Audit Journal"]
        CDJ["Compact Document Journal"]
    end

    OTC --> AR
    PTP --> AP
    ATR --> AA
    BTS --> GL
    HTR --> GL
    RTR --> GL

    AR --> GL
    AP --> GL
    AA --> GL

    GL --> CO
    CO --> PA

    GL --> RPT
    AR --> RPT
    AP --> RPT
    AA --> RPT

    class OTC,PTP,ATR,RTR,BTS,HTR business
    class GL,AP,AR,AA application
    class CO,CCA,PCA,PA integration
    class RPT,FS,AJ,CDJ reporting

Analysis: Core Process Flow Walkthroughs

Record-to-Report — General Ledger

The GL is the final integration point for every financial event in the enterprise. Journal entries arrive both automatically from upstream processes and manually from accounting staff. Open item management, foreign currency valuation, period locking, and subledger reconciliation are all GL responsibilities. The period-end close sequence begins and ends here.

flowchart TD
    classDef step fill:#b8d4f0,stroke:#1565c0
    classDef close fill:#fff3b0,stroke:#cc9a06
    classDef report fill:#f3e5f5,stroke:#6a1b9a

    A["Business Event<br>(Sale / Purchase / Payroll / Goods Movement)"]
    B["Upstream Process Posting<br>(SD / MM / HR / PP)"]
    C["Automatic FI Document<br>Generated in GL"]
    D["Journal Entry Review<br>& Manual Postings"]
    E["Open Item Management<br>& Clearing"]
    F["Period-End Closing<br>(Period Control / Subledger Recon)"]
    G["Balance Carryforward"]
    H["Financial Statement<br>Generation"]
    I["Audit Journal / Compact<br>Document Journal"]

    A --> B --> C --> D --> E --> F --> G --> H
    F --> I
    H --> I

    class A,B,C,D,E step
    class F,G close
    class H,I report

Record-to-Report as a Standard Process Flow

The GL flow — business event through financial statements on the Universal Journal — as a BPMN 2.0 process:

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Record-to-Report through the GL — business event to financial statements on the Universal Journal (FI process architecture).
  Canonical BPMN 2.0 (Plan 01): standard namespaces, stable ids, DI included
  so the file imports cleanly into Camunda / Signavio / ARIS / Bizagi.
-->
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="Defs_FiRecordToReport"
                  targetNamespace="https://docs.sajivfrancis.com/bpmn">
  <bpmn:process id="Process_FiRecordToReport" name="Record-to-Report — General Ledger (FI-GL)" isExecutable="false">
    <bpmn:startEvent id="Start_Event" name="Business event occurs (sale / purchase / payroll / goods movement)">
      <bpmn:outgoing>Flow_1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task_Upstream" name="Upstream process posts (SD / MM / HR / PP)">
      <bpmn:incoming>Flow_1</bpmn:incoming>
      <bpmn:outgoing>Flow_2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_AutoDoc" name="Automatic FI document generated in GL (ACDOCA)">
      <bpmn:incoming>Flow_2</bpmn:incoming>
      <bpmn:outgoing>Flow_3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Manual" name="Review journal entries; post manual adjustments (FB50)">
      <bpmn:incoming>Flow_3</bpmn:incoming>
      <bpmn:outgoing>Flow_4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_OpenItems" name="Manage and clear open items">
      <bpmn:incoming>Flow_4</bpmn:incoming>
      <bpmn:outgoing>Flow_5</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Close" name="Period-end close (period lock, subledger reconciliation)">
      <bpmn:incoming>Flow_5</bpmn:incoming>
      <bpmn:outgoing>Flow_6</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_YearEnd" name="Year-end close?">
      <bpmn:incoming>Flow_6</bpmn:incoming>
      <bpmn:outgoing>Flow_7</bpmn:outgoing>
      <bpmn:outgoing>Flow_8</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_Carryforward" name="Execute balance carryforward">
      <bpmn:incoming>Flow_8</bpmn:incoming>
      <bpmn:outgoing>Flow_9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Statements" name="Generate financial statements (F.01)">
      <bpmn:incoming>Flow_7</bpmn:incoming>
      <bpmn:incoming>Flow_9</bpmn:incoming>
      <bpmn:outgoing>Flow_10</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Audit" name="Audit Journal / Compact Document Journal (F0997)">
      <bpmn:incoming>Flow_10</bpmn:incoming>
      <bpmn:outgoing>Flow_11</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End_Reported" name="Legal and management reporting complete">
      <bpmn:incoming>Flow_11</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow_1" sourceRef="Start_Event" targetRef="Task_Upstream" />
    <bpmn:sequenceFlow id="Flow_2" sourceRef="Task_Upstream" targetRef="Task_AutoDoc" />
    <bpmn:sequenceFlow id="Flow_3" sourceRef="Task_AutoDoc" targetRef="Task_Manual" />
    <bpmn:sequenceFlow id="Flow_4" sourceRef="Task_Manual" targetRef="Task_OpenItems" />
    <bpmn:sequenceFlow id="Flow_5" sourceRef="Task_OpenItems" targetRef="Task_Close" />
    <bpmn:sequenceFlow id="Flow_6" sourceRef="Task_Close" targetRef="Gw_YearEnd" />
    <bpmn:sequenceFlow id="Flow_7" name="No — monthly" sourceRef="Gw_YearEnd" targetRef="Task_Statements" />
    <bpmn:sequenceFlow id="Flow_8" name="Yes" sourceRef="Gw_YearEnd" targetRef="Task_Carryforward" />
    <bpmn:sequenceFlow id="Flow_9" sourceRef="Task_Carryforward" targetRef="Task_Statements" />
    <bpmn:sequenceFlow id="Flow_10" sourceRef="Task_Statements" targetRef="Task_Audit" />
    <bpmn:sequenceFlow id="Flow_11" sourceRef="Task_Audit" targetRef="End_Reported" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="Diagram_Process_FiRecordToReport">
    <bpmndi:BPMNPlane id="Plane_Process_FiRecordToReport" bpmnElement="Process_FiRecordToReport">
      <bpmndi:BPMNShape id="Shape_Start_Event" bpmnElement="Start_Event">
        <dc:Bounds x="202" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Upstream" bpmnElement="Task_Upstream">
        <dc:Bounds x="330" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_AutoDoc" bpmnElement="Task_AutoDoc">
        <dc:Bounds x="500" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Manual" bpmnElement="Task_Manual">
        <dc:Bounds x="670" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_OpenItems" bpmnElement="Task_OpenItems">
        <dc:Bounds x="840" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Close" bpmnElement="Task_Close">
        <dc:Bounds x="1010" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Gw_YearEnd" bpmnElement="Gw_YearEnd" isMarkerVisible="true">
        <dc:Bounds x="1215" y="235" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Carryforward" bpmnElement="Task_Carryforward">
        <dc:Bounds x="1350" y="360" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Statements" bpmnElement="Task_Statements">
        <dc:Bounds x="1520" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Audit" bpmnElement="Task_Audit">
        <dc:Bounds x="1690" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_End_Reported" bpmnElement="End_Reported">
        <dc:Bounds x="1902" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Edge_Flow_1" bpmnElement="Flow_1">
        <di:waypoint x="238" y="260" />
        <di:waypoint x="330" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_2" bpmnElement="Flow_2">
        <di:waypoint x="450" y="260" />
        <di:waypoint x="500" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_3" bpmnElement="Flow_3">
        <di:waypoint x="620" y="260" />
        <di:waypoint x="670" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_4" bpmnElement="Flow_4">
        <di:waypoint x="790" y="260" />
        <di:waypoint x="840" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_5" bpmnElement="Flow_5">
        <di:waypoint x="960" y="260" />
        <di:waypoint x="1010" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_6" bpmnElement="Flow_6">
        <di:waypoint x="1130" y="260" />
        <di:waypoint x="1215" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_7" bpmnElement="Flow_7">
        <di:waypoint x="1265" y="260" />
        <di:waypoint x="1520" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_8" bpmnElement="Flow_8">
        <di:waypoint x="1240" y="285" />
        <di:waypoint x="1240" y="400" />
        <di:waypoint x="1350" y="400" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_9" bpmnElement="Flow_9">
        <di:waypoint x="1470" y="400" />
        <di:waypoint x="1495" y="400" />
        <di:waypoint x="1495" y="260" />
        <di:waypoint x="1520" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_10" bpmnElement="Flow_10">
        <di:waypoint x="1640" y="260" />
        <di:waypoint x="1690" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_11" bpmnElement="Flow_11">
        <di:waypoint x="1810" y="260" />
        <di:waypoint x="1902" y="260" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

Order-to-Cash — Accounts Receivable (FI-AR)

The sales order is the initiating event for all downstream AR postings. Credit management and dunning are embedded controls — credit limits enforced at order entry, dunning levels tracked per open item. Four swim lanes: Customer → Sales & Distribution → Logistics Execution → Financial Accounting.

flowchart TD
    classDef customer fill:#fff3e0,stroke:#e65100
    classDef sd fill:#e8f5e9,stroke:#2e7d32
    classDef log fill:#e3f2fd,stroke:#1565c0
    classDef fi fill:#f3e5f5,stroke:#6a1b9a
    classDef gateway fill:#fff3b0,stroke:#cc9a06

    subgraph CUST["🧑 Customer"]
        C1["Inquiry / RFQ"]
        C2["Purchase Order<br>Issued"]
        C3["Receives Goods<br>or Service"]
        C4["Reviews Invoice"]
        C5["Remits Payment"]
        C6["Raises Dispute"]
    end

    subgraph SD["📦 Sales & Distribution"]
        S1["Quotation Created"]
        S2["Sales Order Created"]
        S3["Credit Limit Check"]
        S4["Credit Block<br>Released / Escalated"]
        S5["Billing Document<br>Created"]
        S6["Credit Memo<br>Request"]
    end

    subgraph LOG["🚚 Logistics Execution"]
        L1["Delivery Order<br>Created"]
        L2["Goods Issue<br>Posted"]
    end

    subgraph FI["💰 Financial Accounting — AR"]
        F1["Customer Invoice<br>Posted in FI-AR"]
        F2["Open Item Created<br>in AR Subledger"]
        F3["GL Account Updated<br>(Real-Time)"]
        F4["Incoming Payment<br>Recorded"]
        F5["Open Item Cleared"]
        F6["Dunning Run<br>Executed"]
        F7["Dunning Notice<br>Issued"]
        F8["Credit Memo<br>Posted"]
        F9["Down Payment<br>Request / Posting"]
        F10["AR Subledger<br>Reconciled to GL"]
    end

    subgraph GW["⬡ Gateways"]
        G1{"Credit Check<br>Passed?"}
        G2{"Payment<br>Received?"}
        G3{"Dispute<br>Valid?"}
    end

    C1 --> S1 --> C2 --> S2 --> S3 --> G1
    G1 -->|Yes| L1
    G1 -->|No| S4
    S4 -->|Released| L1
    S4 -->|Blocked| S2

    L1 --> L2 --> C3 --> S5 --> F1
    F1 --> F2 --> F3
    F2 --> G2

    C4 --> C5
    C5 --> F4 --> F5 --> F10
    G2 -->|"Overdue"| F6 --> F7 --> C4
    C4 --> C6 --> G3
    G3 -->|Yes| S6 --> F8 --> F5
    G3 -->|No| F7

    S2 -->|"Advance Payment"| F9 --> F3

    class C1,C2,C3,C4,C5,C6 customer
    class S1,S2,S3,S4,S5,S6 sd
    class L1,L2 log
    class F1,F2,F3,F4,F5,F6,F7,F8,F9,F10 fi
    class G1,G2,G3 gateway

AR Key Control Points

Control	Where	SAP Mechanism
Credit limit check	Sales Order entry	Credit Management (FI-AR-CR)
3-party billing match	Billing → FI posting	Billing document → FI-AR auto post
Dunning levels	Open item aging	Dunning program — configurable levels
Dispute resolution	Credit memo workflow	Credit memo request → approval → FI post
Subledger ↔ GL reconciliation	Real-time	Reconciliation account on customer master

Order-to-Cash as a Standard Process Flow

The AR cycle — sales order and credit check through billing, dunning, and cash application — as a BPMN 2.0 process:

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Order-to-Cash through FI-AR — sales order, credit check, billing, dunning, cash application (FI process architecture).
  Canonical BPMN 2.0 (Plan 01): standard namespaces, stable ids, DI included
  so the file imports cleanly into Camunda / Signavio / ARIS / Bizagi.
-->
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="Defs_FiOrderToCash"
                  targetNamespace="https://docs.sajivfrancis.com/bpmn">
  <bpmn:process id="Process_FiOrderToCash" name="Order-to-Cash — Accounts Receivable (FI-AR)" isExecutable="false">
    <bpmn:startEvent id="Start_Order" name="Sales order created (VA01)">
      <bpmn:outgoing>Flow_1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:exclusiveGateway id="Gw_Credit" name="Credit check passed?">
      <bpmn:incoming>Flow_1</bpmn:incoming>
      <bpmn:outgoing>Flow_2</bpmn:outgoing>
      <bpmn:outgoing>Flow_3</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_CreditRelease" name="Release credit block (VKM3)">
      <bpmn:incoming>Flow_3</bpmn:incoming>
      <bpmn:outgoing>Flow_4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Delivery" name="Create delivery and post goods issue (VL01N)">
      <bpmn:incoming>Flow_2</bpmn:incoming>
      <bpmn:incoming>Flow_4</bpmn:incoming>
      <bpmn:outgoing>Flow_5</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Billing" name="Create billing document (VF01)">
      <bpmn:incoming>Flow_5</bpmn:incoming>
      <bpmn:outgoing>Flow_6</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_PostInvoice" name="Customer invoice auto-posted to FI-AR / ACDOCA">
      <bpmn:incoming>Flow_6</bpmn:incoming>
      <bpmn:outgoing>Flow_7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_Paid" name="Payment received by due date?">
      <bpmn:incoming>Flow_7</bpmn:incoming>
      <bpmn:outgoing>Flow_8</bpmn:outgoing>
      <bpmn:outgoing>Flow_9</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_Dunning" name="Run dunning (F150); issue dunning notice">
      <bpmn:incoming>Flow_9</bpmn:incoming>
      <bpmn:outgoing>Flow_10</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Payment" name="Post incoming payment (F-28)">
      <bpmn:incoming>Flow_8</bpmn:incoming>
      <bpmn:incoming>Flow_10</bpmn:incoming>
      <bpmn:outgoing>Flow_11</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Clear" name="Clear open item; AR reconciles to GL in real time">
      <bpmn:incoming>Flow_11</bpmn:incoming>
      <bpmn:outgoing>Flow_12</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End_Cleared" name="Cash collected — open item cleared">
      <bpmn:incoming>Flow_12</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow_1" sourceRef="Start_Order" targetRef="Gw_Credit" />
    <bpmn:sequenceFlow id="Flow_2" name="Yes" sourceRef="Gw_Credit" targetRef="Task_Delivery" />
    <bpmn:sequenceFlow id="Flow_3" name="No — blocked" sourceRef="Gw_Credit" targetRef="Task_CreditRelease" />
    <bpmn:sequenceFlow id="Flow_4" name="Released" sourceRef="Task_CreditRelease" targetRef="Task_Delivery" />
    <bpmn:sequenceFlow id="Flow_5" sourceRef="Task_Delivery" targetRef="Task_Billing" />
    <bpmn:sequenceFlow id="Flow_6" sourceRef="Task_Billing" targetRef="Task_PostInvoice" />
    <bpmn:sequenceFlow id="Flow_7" sourceRef="Task_PostInvoice" targetRef="Gw_Paid" />
    <bpmn:sequenceFlow id="Flow_8" name="Yes" sourceRef="Gw_Paid" targetRef="Task_Payment" />
    <bpmn:sequenceFlow id="Flow_9" name="Overdue" sourceRef="Gw_Paid" targetRef="Task_Dunning" />
    <bpmn:sequenceFlow id="Flow_10" name="Customer remits" sourceRef="Task_Dunning" targetRef="Task_Payment" />
    <bpmn:sequenceFlow id="Flow_11" sourceRef="Task_Payment" targetRef="Task_Clear" />
    <bpmn:sequenceFlow id="Flow_12" sourceRef="Task_Clear" targetRef="End_Cleared" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="Diagram_Process_FiOrderToCash">
    <bpmndi:BPMNPlane id="Plane_Process_FiOrderToCash" bpmnElement="Process_FiOrderToCash">
      <bpmndi:BPMNShape id="Shape_Start_Order" bpmnElement="Start_Order">
        <dc:Bounds x="202" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Gw_Credit" bpmnElement="Gw_Credit" isMarkerVisible="true">
        <dc:Bounds x="365" y="235" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_CreditRelease" bpmnElement="Task_CreditRelease">
        <dc:Bounds x="500" y="360" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Delivery" bpmnElement="Task_Delivery">
        <dc:Bounds x="670" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Billing" bpmnElement="Task_Billing">
        <dc:Bounds x="840" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_PostInvoice" bpmnElement="Task_PostInvoice">
        <dc:Bounds x="1010" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Gw_Paid" bpmnElement="Gw_Paid" isMarkerVisible="true">
        <dc:Bounds x="1215" y="235" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Dunning" bpmnElement="Task_Dunning">
        <dc:Bounds x="1350" y="360" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Payment" bpmnElement="Task_Payment">
        <dc:Bounds x="1520" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Clear" bpmnElement="Task_Clear">
        <dc:Bounds x="1690" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_End_Cleared" bpmnElement="End_Cleared">
        <dc:Bounds x="1902" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Edge_Flow_1" bpmnElement="Flow_1">
        <di:waypoint x="238" y="260" />
        <di:waypoint x="365" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_2" bpmnElement="Flow_2">
        <di:waypoint x="415" y="260" />
        <di:waypoint x="670" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_3" bpmnElement="Flow_3">
        <di:waypoint x="390" y="285" />
        <di:waypoint x="390" y="400" />
        <di:waypoint x="500" y="400" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_4" bpmnElement="Flow_4">
        <di:waypoint x="620" y="400" />
        <di:waypoint x="645" y="400" />
        <di:waypoint x="645" y="260" />
        <di:waypoint x="670" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_5" bpmnElement="Flow_5">
        <di:waypoint x="790" y="260" />
        <di:waypoint x="840" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_6" bpmnElement="Flow_6">
        <di:waypoint x="960" y="260" />
        <di:waypoint x="1010" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_7" bpmnElement="Flow_7">
        <di:waypoint x="1130" y="260" />
        <di:waypoint x="1215" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_8" bpmnElement="Flow_8">
        <di:waypoint x="1265" y="260" />
        <di:waypoint x="1520" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_9" bpmnElement="Flow_9">
        <di:waypoint x="1240" y="285" />
        <di:waypoint x="1240" y="400" />
        <di:waypoint x="1350" y="400" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_10" bpmnElement="Flow_10">
        <di:waypoint x="1470" y="400" />
        <di:waypoint x="1495" y="400" />
        <di:waypoint x="1495" y="260" />
        <di:waypoint x="1520" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_11" bpmnElement="Flow_11">
        <di:waypoint x="1640" y="260" />
        <di:waypoint x="1690" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_12" bpmnElement="Flow_12">
        <di:waypoint x="1810" y="260" />
        <di:waypoint x="1902" y="260" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

Purchase-to-Pay — Accounts Payable (FI-AP)

Every AP posting generates a corresponding GL entry in real time — AP subledger and GL reconcile continuously. Five swim lanes: Vendor → Procurement → Warehouse / Goods Receipt → Invoice Verification → Financial Accounting.

flowchart TD
    classDef vendor fill:#fff3e0,stroke:#e65100
    classDef proc fill:#e8f5e9,stroke:#2e7d32
    classDef wh fill:#e3f2fd,stroke:#1565c0
    classDef iv fill:#fff3b0,stroke:#cc9a06
    classDef fi fill:#f3e5f5,stroke:#6a1b9a
    classDef gateway fill:#dce8ff,stroke:#3949ab

    subgraph VEND["🏭 Vendor"]
        V1["Receives RFQ"]
        V2["Submits Quotation"]
        V3["Confirms PO"]
        V4["Delivers Goods<br>or Service"]
        V5["Sends Invoice"]
        V6["Receives Payment"]
    end

    subgraph PROC["📋 Procurement"]
        P1["Purchase Requisition<br>Created"]
        P2["RFQ Issued"]
        P3["Quotation Evaluated"]
        P4["Purchase Order<br>Created"]
        P5["Contract / Release<br>Order"]
        P6["Service Entry Sheet<br>(if applicable)"]
    end

    subgraph WH["🏗️ Warehouse / Goods Receipt"]
        W1["Goods Receipt<br>Posted (MIGO)"]
        W2["GR Document<br>Created in MM"]
        W3["Inventory Account<br>Updated"]
    end

    subgraph IV["🧾 Invoice Verification"]
        I1["Vendor Invoice<br>Entered (MIRO)"]
        I2["3-Way Match<br>(PO / GR / Invoice)"]
        I3["Tolerance Check"]
        I4["Invoice Blocked<br>for Payment"]
        I5["Invoice Approved"]
        I6["Credit Memo<br>Received & Posted"]
    end

    subgraph FI["💰 Financial Accounting — AP"]
        F1["AP Document<br>Posted in FI-AP"]
        F2["Open Item Created<br>in AP Subledger"]
        F3["GL Account Updated<br>(Real-Time)"]
        F4["Payment Proposal<br>Generated"]
        F5["Payment Run<br>Executed"]
        F6["Bank Transfer /<br>Check Issued"]
        F7["Open Item Cleared"]
        F8["Down Payment<br>Posted"]
        F9["AP Subledger<br>Reconciled to GL"]
    end

    subgraph GW["⬡ Gateways"]
        G1{"PO Required?"}
        G2{"3-Way Match<br>OK?"}
        G3{"Within<br>Tolerance?"}
        G4{"Payment<br>Approved?"}
    end

    P1 --> G1
    G1 -->|Yes| P2 --> V1 --> V2 --> P3 --> P4
    G1 -->|"Contract Exists"| P5
    P4 --> V3 --> V4
    P5 --> V4

    V4 --> W1 --> W2 --> W3
    W3 --> I1
    V5 --> I1
    P4 -->|"Service"| P6 --> I1

    I1 --> I2 --> G2
    G2 -->|Match| I3 --> G3
    G2 -->|"Mismatch"| I4
    I4 -->|Resolved| I5
    G3 -->|OK| I5
    G3 -->|"Exceeds Tolerance"| I4

    I5 --> F1 --> F2 --> F3
    I6 --> F1
    F2 --> F4 --> G4
    G4 -->|Approved| F5 --> F6 --> V6
    F6 --> F7 --> F9
    G4 -->|Rejected| F4

    P4 -->|"Advance"| F8 --> F3

    class V1,V2,V3,V4,V5,V6 vendor
    class P1,P2,P3,P4,P5,P6 proc
    class W1,W2,W3 wh
    class I1,I2,I3,I4,I5,I6 iv
    class F1,F2,F3,F4,F5,F6,F7,F8,F9 fi
    class G1,G2,G3,G4 gateway

AP Key Control Points

Control	Where	SAP Mechanism
Purchase requisition authorization	Before PO	Release strategy (MM)
3-way match	Invoice verification	MIRO automatic PO/GR/IR match
Tolerance limits	Invoice verification	Tolerance keys (MM / FI)
Payment block	Post-match exception	Manual / automatic block flags
Dual control on payments	Payment run	Payment approval workflow
Subledger ↔ GL reconciliation	Real-time	Reconciliation account on vendor master

Purchase-to-Pay as a Standard Process Flow

The AP cycle — requisition through 3-way match, payment run, and clearing — as a BPMN 2.0 process:

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Purchase-to-Pay through FI-AP — requisition, 3-way match, payment run with approval loop (FI process architecture).
  Canonical BPMN 2.0 (Plan 01): standard namespaces, stable ids, DI included
  so the file imports cleanly into Camunda / Signavio / ARIS / Bizagi.
-->
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="Defs_FiPurchaseToPay"
                  targetNamespace="https://docs.sajivfrancis.com/bpmn">
  <bpmn:process id="Process_FiPurchaseToPay" name="Purchase-to-Pay — Accounts Payable (FI-AP)" isExecutable="false">
    <bpmn:startEvent id="Start_Demand" name="Purchase requisition created">
      <bpmn:outgoing>Flow_1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task_Po" name="Create purchase order (release strategy applied)">
      <bpmn:incoming>Flow_1</bpmn:incoming>
      <bpmn:outgoing>Flow_2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Gr" name="Post goods receipt (MIGO 101)">
      <bpmn:incoming>Flow_2</bpmn:incoming>
      <bpmn:outgoing>Flow_3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Invoice" name="Enter vendor invoice (MIRO)">
      <bpmn:incoming>Flow_3</bpmn:incoming>
      <bpmn:outgoing>Flow_4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_Match" name="3-way match within tolerance?">
      <bpmn:incoming>Flow_4</bpmn:incoming>
      <bpmn:outgoing>Flow_5</bpmn:outgoing>
      <bpmn:outgoing>Flow_6</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_Block" name="Block invoice; resolve quantity / price difference">
      <bpmn:incoming>Flow_6</bpmn:incoming>
      <bpmn:outgoing>Flow_7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_PostAp" name="Post AP document to FI-AP / ACDOCA">
      <bpmn:incoming>Flow_5</bpmn:incoming>
      <bpmn:incoming>Flow_7</bpmn:incoming>
      <bpmn:outgoing>Flow_8</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Proposal" name="Run payment proposal (F110)">
      <bpmn:incoming>Flow_8</bpmn:incoming>
      <bpmn:incoming>Flow_11</bpmn:incoming>
      <bpmn:outgoing>Flow_9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_Approve" name="Payment approved?">
      <bpmn:incoming>Flow_9</bpmn:incoming>
      <bpmn:outgoing>Flow_10</bpmn:outgoing>
      <bpmn:outgoing>Flow_11</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_Pay" name="Execute payment run; issue transfer / check">
      <bpmn:incoming>Flow_10</bpmn:incoming>
      <bpmn:outgoing>Flow_12</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Clear" name="Clear open item; AP reconciles to GL in real time">
      <bpmn:incoming>Flow_12</bpmn:incoming>
      <bpmn:outgoing>Flow_13</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End_Paid" name="Vendor paid — liability discharged">
      <bpmn:incoming>Flow_13</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow_1" sourceRef="Start_Demand" targetRef="Task_Po" />
    <bpmn:sequenceFlow id="Flow_2" sourceRef="Task_Po" targetRef="Task_Gr" />
    <bpmn:sequenceFlow id="Flow_3" sourceRef="Task_Gr" targetRef="Task_Invoice" />
    <bpmn:sequenceFlow id="Flow_4" sourceRef="Task_Invoice" targetRef="Gw_Match" />
    <bpmn:sequenceFlow id="Flow_5" name="Yes" sourceRef="Gw_Match" targetRef="Task_PostAp" />
    <bpmn:sequenceFlow id="Flow_6" name="No" sourceRef="Gw_Match" targetRef="Task_Block" />
    <bpmn:sequenceFlow id="Flow_7" name="Resolved" sourceRef="Task_Block" targetRef="Task_PostAp" />
    <bpmn:sequenceFlow id="Flow_8" sourceRef="Task_PostAp" targetRef="Task_Proposal" />
    <bpmn:sequenceFlow id="Flow_9" sourceRef="Task_Proposal" targetRef="Gw_Approve" />
    <bpmn:sequenceFlow id="Flow_10" name="Approved" sourceRef="Gw_Approve" targetRef="Task_Pay" />
    <bpmn:sequenceFlow id="Flow_11" name="Rejected — rework" sourceRef="Gw_Approve" targetRef="Task_Proposal" />
    <bpmn:sequenceFlow id="Flow_12" sourceRef="Task_Pay" targetRef="Task_Clear" />
    <bpmn:sequenceFlow id="Flow_13" sourceRef="Task_Clear" targetRef="End_Paid" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="Diagram_Process_FiPurchaseToPay">
    <bpmndi:BPMNPlane id="Plane_Process_FiPurchaseToPay" bpmnElement="Process_FiPurchaseToPay">
      <bpmndi:BPMNShape id="Shape_Start_Demand" bpmnElement="Start_Demand">
        <dc:Bounds x="202" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Po" bpmnElement="Task_Po">
        <dc:Bounds x="330" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Gr" bpmnElement="Task_Gr">
        <dc:Bounds x="500" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Invoice" bpmnElement="Task_Invoice">
        <dc:Bounds x="670" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Gw_Match" bpmnElement="Gw_Match" isMarkerVisible="true">
        <dc:Bounds x="875" y="235" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Block" bpmnElement="Task_Block">
        <dc:Bounds x="1010" y="360" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_PostAp" bpmnElement="Task_PostAp">
        <dc:Bounds x="1180" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Proposal" bpmnElement="Task_Proposal">
        <dc:Bounds x="1350" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Gw_Approve" bpmnElement="Gw_Approve" isMarkerVisible="true">
        <dc:Bounds x="1555" y="235" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Pay" bpmnElement="Task_Pay">
        <dc:Bounds x="1690" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Clear" bpmnElement="Task_Clear">
        <dc:Bounds x="1860" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_End_Paid" bpmnElement="End_Paid">
        <dc:Bounds x="2072" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Edge_Flow_1" bpmnElement="Flow_1">
        <di:waypoint x="238" y="260" />
        <di:waypoint x="330" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_2" bpmnElement="Flow_2">
        <di:waypoint x="450" y="260" />
        <di:waypoint x="500" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_3" bpmnElement="Flow_3">
        <di:waypoint x="620" y="260" />
        <di:waypoint x="670" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_4" bpmnElement="Flow_4">
        <di:waypoint x="790" y="260" />
        <di:waypoint x="875" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_5" bpmnElement="Flow_5">
        <di:waypoint x="925" y="260" />
        <di:waypoint x="1180" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_6" bpmnElement="Flow_6">
        <di:waypoint x="900" y="285" />
        <di:waypoint x="900" y="400" />
        <di:waypoint x="1010" y="400" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_7" bpmnElement="Flow_7">
        <di:waypoint x="1130" y="400" />
        <di:waypoint x="1155" y="400" />
        <di:waypoint x="1155" y="260" />
        <di:waypoint x="1180" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_8" bpmnElement="Flow_8">
        <di:waypoint x="1300" y="260" />
        <di:waypoint x="1350" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_9" bpmnElement="Flow_9">
        <di:waypoint x="1470" y="260" />
        <di:waypoint x="1555" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_10" bpmnElement="Flow_10">
        <di:waypoint x="1605" y="260" />
        <di:waypoint x="1690" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_11" bpmnElement="Flow_11">
        <di:waypoint x="1580" y="285" />
        <di:waypoint x="1580" y="360" />
        <di:waypoint x="1410" y="360" />
        <di:waypoint x="1410" y="300" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_12" bpmnElement="Flow_12">
        <di:waypoint x="1810" y="260" />
        <di:waypoint x="1860" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_13" bpmnElement="Flow_13">
        <di:waypoint x="1980" y="260" />
        <di:waypoint x="2072" y="260" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

Acquire-to-Retire — Fixed Asset Accounting (FI-AA)

Fixed Asset Accounting is a subledger of FI — every asset account is linked through an asset class to a GL reconciliation account. Depreciation runs touch many accounts simultaneously. The determination of whether an expenditure is an asset or an expense has material impact on reported results and is a key audit and governance control point.

flowchart TD
    classDef step fill:#e8f5e9,stroke:#2e7d32
    classDef valuation fill:#fff3b0,stroke:#cc9a06
    classDef report fill:#f3e5f5,stroke:#6a1b9a

    A["Asset Acquisition<br>(Purchase / Internal Construction)"]
    B["Asset Master Record Created<br>(Asset Class assigned)"]
    C["Capitalization<br>(Asset Reconciliation Account → GL)"]
    D["Depreciation Run<br>(Periodic / Planned)"]
    E["Revaluation / Impairment"]
    F["Asset Retirement<br>(Sale / Scrapping)"]
    G["Period-End Closing<br>(FI-AA)"]
    H["Fixed Asset Reports<br>& Financial Statement"]

    A --> B --> C --> D --> E --> F --> G --> H
    D --> G
    E --> G

    class A,B,C step
    class D,E valuation
    class F,G,H report

Acquire-to-Retire as a Standard Process Flow

The asset lifecycle — capitalisation through the periodic depreciation loop to retirement — as a BPMN 2.0 process:

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Acquire-to-Retire through FI-AA — capitalisation, periodic depreciation loop, retirement (FI process architecture).
  Canonical BPMN 2.0 (Plan 01): standard namespaces, stable ids, DI included
  so the file imports cleanly into Camunda / Signavio / ARIS / Bizagi.
-->
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="Defs_FiAcquireToRetire"
                  targetNamespace="https://docs.sajivfrancis.com/bpmn">
  <bpmn:process id="Process_FiAcquireToRetire" name="Acquire-to-Retire — Fixed Asset Accounting (FI-AA)" isExecutable="false">
    <bpmn:startEvent id="Start_Acq" name="Asset acquisition approved (purchase / internal build)">
      <bpmn:outgoing>Flow_1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task_Master" name="Create asset master record (AS01, asset class)">
      <bpmn:incoming>Flow_1</bpmn:incoming>
      <bpmn:outgoing>Flow_2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Cap" name="Capitalise asset (reconciliation account posts to GL)">
      <bpmn:incoming>Flow_2</bpmn:incoming>
      <bpmn:outgoing>Flow_3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Depr" name="Run periodic depreciation (AFAB)">
      <bpmn:incoming>Flow_3</bpmn:incoming>
      <bpmn:incoming>Flow_6</bpmn:incoming>
      <bpmn:outgoing>Flow_4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Reval" name="Post revaluation / impairment where required">
      <bpmn:incoming>Flow_4</bpmn:incoming>
      <bpmn:outgoing>Flow_5</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_Life" name="Asset still in service?">
      <bpmn:incoming>Flow_5</bpmn:incoming>
      <bpmn:outgoing>Flow_6</bpmn:outgoing>
      <bpmn:outgoing>Flow_7</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_Retire" name="Retire asset (ABAVN — sale / scrapping)">
      <bpmn:incoming>Flow_7</bpmn:incoming>
      <bpmn:outgoing>Flow_8</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Close" name="FI-AA period-end close and asset reporting">
      <bpmn:incoming>Flow_8</bpmn:incoming>
      <bpmn:outgoing>Flow_9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End_Retired" name="Asset retired; NBV settled to GL">
      <bpmn:incoming>Flow_9</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow_1" sourceRef="Start_Acq" targetRef="Task_Master" />
    <bpmn:sequenceFlow id="Flow_2" sourceRef="Task_Master" targetRef="Task_Cap" />
    <bpmn:sequenceFlow id="Flow_3" sourceRef="Task_Cap" targetRef="Task_Depr" />
    <bpmn:sequenceFlow id="Flow_4" sourceRef="Task_Depr" targetRef="Task_Reval" />
    <bpmn:sequenceFlow id="Flow_5" sourceRef="Task_Reval" targetRef="Gw_Life" />
    <bpmn:sequenceFlow id="Flow_6" name="Yes — next period" sourceRef="Gw_Life" targetRef="Task_Depr" />
    <bpmn:sequenceFlow id="Flow_7" name="No" sourceRef="Gw_Life" targetRef="Task_Retire" />
    <bpmn:sequenceFlow id="Flow_8" sourceRef="Task_Retire" targetRef="Task_Close" />
    <bpmn:sequenceFlow id="Flow_9" sourceRef="Task_Close" targetRef="End_Retired" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="Diagram_Process_FiAcquireToRetire">
    <bpmndi:BPMNPlane id="Plane_Process_FiAcquireToRetire" bpmnElement="Process_FiAcquireToRetire">
      <bpmndi:BPMNShape id="Shape_Start_Acq" bpmnElement="Start_Acq">
        <dc:Bounds x="202" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Master" bpmnElement="Task_Master">
        <dc:Bounds x="330" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Cap" bpmnElement="Task_Cap">
        <dc:Bounds x="500" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Depr" bpmnElement="Task_Depr">
        <dc:Bounds x="670" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Reval" bpmnElement="Task_Reval">
        <dc:Bounds x="840" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Gw_Life" bpmnElement="Gw_Life" isMarkerVisible="true">
        <dc:Bounds x="1045" y="235" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Retire" bpmnElement="Task_Retire">
        <dc:Bounds x="1180" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Close" bpmnElement="Task_Close">
        <dc:Bounds x="1350" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_End_Retired" bpmnElement="End_Retired">
        <dc:Bounds x="1562" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Edge_Flow_1" bpmnElement="Flow_1">
        <di:waypoint x="238" y="260" />
        <di:waypoint x="330" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_2" bpmnElement="Flow_2">
        <di:waypoint x="450" y="260" />
        <di:waypoint x="500" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_3" bpmnElement="Flow_3">
        <di:waypoint x="620" y="260" />
        <di:waypoint x="670" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_4" bpmnElement="Flow_4">
        <di:waypoint x="790" y="260" />
        <di:waypoint x="840" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_5" bpmnElement="Flow_5">
        <di:waypoint x="960" y="260" />
        <di:waypoint x="1045" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_6" bpmnElement="Flow_6">
        <di:waypoint x="1070" y="285" />
        <di:waypoint x="1070" y="360" />
        <di:waypoint x="730" y="360" />
        <di:waypoint x="730" y="300" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_7" bpmnElement="Flow_7">
        <di:waypoint x="1095" y="260" />
        <di:waypoint x="1180" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_8" bpmnElement="Flow_8">
        <di:waypoint x="1300" y="260" />
        <di:waypoint x="1350" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_9" bpmnElement="Flow_9">
        <di:waypoint x="1470" y="260" />
        <di:waypoint x="1562" y="260" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

Analysis: Universal Journal Architecture

What the Universal Journal Changes

The Universal Journal (ACDOCA) is the S/4HANA architectural centerpiece — a single line-item table that merges what were previously separate data stores in ECC: the FI document table (BSEG), CO line items (COEP), Asset Accounting (ANEP), Material Ledger (MLCD), and Profitability Analysis (CE4xxxx). This eliminates the reconciliation ledger entirely and makes FI-CO alignment a structural property of the system rather than a periodic closing task.

ECC Architecture	S/4HANA Universal Journal
FI document table (BSEG) separate from CO (COEP)	Single ACDOCA table — one posting, all dimensions
Reconciliation ledger required for FI-CO alignment	Eliminated — alignment is structural
CO-PA fed by periodic settlement runs	CO-PA attributes stored inline at transaction time
Asset Accounting reconciliation account approach	FI-AA integrated directly into ACDOCA
Multiple aggregated totals tables	SAP HANA in-memory aggregation on demand
Period-end data transfer to BW / reporting	Real-time reporting directly on ACDOCA

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100
    classDef uj fill:#b8d4f0,stroke:#1565c0
    classDef co fill:#e8f5e9,stroke:#2e7d32
    classDef report fill:#f3e5f5,stroke:#6a1b9a

    subgraph UPSTREAM["Upstream Process Sources"]
        U1["SD Billing<br>(Order-to-Cash)"]
        U2["MM / Procurement<br>(Purchase-to-Pay)"]
        U3["PP / Production<br>(Build-to-Stock)"]
        U4["HR / Payroll<br>(Hire-to-Retire)"]
        U5["FI-AA Depreciation<br>(Acquire-to-Retire)"]
        U6["Manual FI<br>Journal Entries"]
        U7["RAR / Revenue<br>Recognition Events"]
    end

    subgraph UJ["📒 Universal Journal — ACDOCA"]
        A1["Single Line-Item Entry:<br>GL Account + Cost Object +<br>Profit Center + Segment +<br>Asset + Material + Customer +<br>Vendor + Functional Area"]
        A2["Parallel Ledgers<br>(IFRS / GAAP / Local)"]
        A3["Parallel Currencies<br>(Company / Group / Hard)"]
        A4["Event-Based<br>Revenue Recognition"]
    end

    subgraph CO_LAYER["Management Accounting — CO"]
        C1["Cost Center Accounting<br>(CCA)"]
        C2["Profit Center Accounting<br>(PCA)"]
        C3["Internal Orders"]
        C4["Profitability Analysis<br>(CO-PA)"]
        C5["Project System<br>(PS)"]
    end

    subgraph RPT["Reporting & Close"]
        R1["Financial Statements<br>(P&L / Balance Sheet)"]
        R2["Segment Reporting"]
        R3["Profitability Reports"]
        R4["Audit Journal<br>(F0997)"]
        R5["Management Reports"]
    end

    U1 --> A1
    U2 --> A1
    U3 --> A1
    U4 --> A1
    U5 --> A1
    U6 --> A1
    U7 --> A4

    A1 --> A2
    A1 --> A3
    A4 --> A1

    A1 --> C1
    A1 --> C2
    A1 --> C3
    A1 --> C4
    A1 --> C5

    A1 --> R1
    A2 --> R1
    C4 --> R3
    C2 --> R2
    A1 --> R4
    C1 --> R5

    class U1,U2,U3,U4,U5,U6,U7 source
    class A1,A2,A3,A4 uj
    class C1,C2,C3,C4,C5 co
    class R1,R2,R3,R4,R5 report

FI ↔ CO Integration

flowchart LR
    classDef application fill:#b8d4f0,stroke:#1565c0
    classDef integration fill:#e8f5e9,stroke:#2e7d32

    GL["General Ledger<br>(FI)"]
    AP["Accounts Payable<br>(FI-AP)"]
    AR["Accounts Receivable<br>(FI-AR)"]
    AA["Fixed Assets<br>(FI-AA)"]

    CO["Management Accounting<br>(CO)"]
    CCA["Cost Center Accounting"]
    PCA["Profit Center Accounting"]
    PA["Profitability Analysis<br>(CO-PA)"]

    AP -->|"Cost postings"| CO
    AR -->|"Revenue postings"| CO
    AA -->|"Depreciation costs"| CO
    GL -->|"Universal Journal<br>(ACDOCA)"| CO

    CO --> CCA
    CO --> PCA
    CO --> PA

    class GL,AP,AR,AA application
    class CO,CCA,PCA,PA integration

Analysis: Period-End Close & Reporting

The S/4HANA period-end close has three structural properties that distinguish it from ECC.

Subledgers reconcile continuously, not at period-end. Because AR, AP, and AA all post in real time to ACDOCA, the traditional batch reconciliation at close is replaced by continuous alignment. The period-end reconciliation check (F.03) becomes a verification step, not a correction exercise.

CO allocations are the last mile before reporting. The GL close gates the CO close — overhead cycles, activity price calculations, and CO-PA assessments cannot meaningfully run until GL is locked. This sequencing is non-negotiable and must be enforced in the close calendar.

Reporting is on-demand from live transaction data. The Audit Journal (F0997) and financial statement apps read directly from ACDOCA — there is no separate data extract or aggregation run required. KPIs are always current and reconciled by design, because there is only one source of truth.

flowchart TD
    classDef sub fill:#fff3e0,stroke:#e65100
    classDef gl fill:#b8d4f0,stroke:#1565c0
    classDef co fill:#e8f5e9,stroke:#2e7d32
    classDef rpt fill:#f3e5f5,stroke:#6a1b9a
    classDef gateway fill:#fff3b0,stroke:#cc9a06

    subgraph SL["📂 Subledger Owners"]
        SL1["AR: Clear Open Items<br>& Dunning Final Run"]
        SL2["AP: Final Payment Run<br>& Clear"]
        SL3["AA: Depreciation Run"]
        SL4["AA: Revaluations<br>& Impairments"]
        SL5["Bank: Final Bank<br>Statements Processed"]
        SL6["Subledger Completeness<br>Confirmed"]
    end

    subgraph GL["📒 General Ledger — Close"]
        G1["Lock Posting Period<br>(Prior Month)"]
        G2["Post Accruals<br>& Deferrals"]
        G3["Foreign Currency<br>Valuation"]
        G4["Intercompany<br>Reconciliation"]
        G5["Subledger to GL<br>Reconciliation Check"]
        G6["Balance Carryforward<br>(Year-End)"]
    end

    subgraph CO["📊 Management Accounting — Close"]
        C1["Repost Parked<br>CO Documents"]
        C2["Overhead Allocation<br>Cycles (CCA)"]
        C3["Activity Price<br>Calculation"]
        C4["WIP Calculation<br>(Production Orders)"]
        C5["Profit Center<br>Distribution"]
        C6["Assessment to<br>CO-PA"]
        C7["CO-FI Reconciliation<br>(Verify ACDOCA)"]
    end

    subgraph RPT["📈 Reporting & Audit"]
        R1["Financial Statement<br>Run (P&L / Balance Sheet)"]
        R2["Segment Reports"]
        R3["Profitability Reports<br>(CO-PA)"]
        R4["Audit Journal<br>(Fiori F0997)"]
        R5["Compact Document<br>Journal"]
        R6["Management Reports<br>(Cost Center / Profit Center)"]
        R7["Disclosure Package<br>Prepared"]
    end

    subgraph GW["⬡ Gateways"]
        GW1{"Subledgers<br>Complete?"}
        GW2{"GL Recon<br>Passed?"}
        GW3{"CO Allocations<br>Complete?"}
        GW4{"Statements<br>Approved?"}
    end

    SL1 --> SL6
    SL2 --> SL6
    SL3 --> SL6
    SL4 --> SL6
    SL5 --> SL6
    SL6 --> GW1

    GW1 -->|"Yes"| G1
    GW1 -->|"Gaps Found"| SL1

    G1 --> G2 --> G3 --> G4 --> G5 --> GW2
    GW2 -->|"Passed"| C1
    GW2 -->|"Differences"| G4

    C1 --> C2 --> C3 --> C4 --> C5 --> C6 --> C7 --> GW3
    GW3 -->|"Complete"| G6
    GW3 -->|"Variances"| C2

    G6 --> R1
    R1 --> GW4
    GW4 -->|"Approved"| R2
    GW4 -->|"Queries"| G2

    R2 --> R7
    R3 --> R7
    R4 --> R7
    R5 --> R7
    R6 --> R7

    C6 --> R3
    C5 --> R2
    G5 --> R4
    G5 --> R5
    C7 --> R6

    class SL1,SL2,SL3,SL4,SL5,SL6 sub
    class G1,G2,G3,G4,G5,G6 gl
    class C1,C2,C3,C4,C5,C6,C7 co
    class R1,R2,R3,R4,R5,R6,R7 rpt
    class GW1,GW2,GW3,GW4 gateway

Close Sequence — Step Reference

Seq	Lane	Step	SAP Transaction / App	Notes
1	Subledger	AR open item clearing	`F.13` / `F-28`	All cash applied before lock
2	Subledger	AP final payment run	`F110`	Ensure no residual open items
3	Subledger	AA depreciation run	`AFAB`	Must run before GL period lock
4	Subledger	Bank statement final	`FF67` / EBRS	All bank lines matched & posted
5	GL	Lock posting period	`OB52`	Prior period locked; current open
6	GL	Accruals & deferrals	`FBS1` / `FBD1`	Manual accruals; recurring entries
7	GL	Foreign currency valuation	`FAGL_FC_VAL`	Open items + GL balances revalued
8	GL	Intercompany reconciliation	`FBICR` / Fiori	Eliminate intercompany differences
9	GL	Subledger ↔ GL check	`F.03` / Fiori recon app	Zero tolerance target
10	CO	Overhead allocation cycles	`KSU5` / `KSV5`	Distribution & assessment runs
11	CO	Activity price calculation	`KSII`	Actual price recalculation
12	CO	WIP calculation	`KKAO`	Production / project orders
13	CO	Profit center distribution	`F.5D`	Align PCA balances
14	CO	Assessment to CO-PA	`KEU5`	Push costs to profitability segments
15	CO	ACDOCA reconciliation	Fiori / `FINS_RCON`	Verify FI = CO on Universal Journal
16	Reporting	Financial statement run	`F.01` / Fiori FS app	P&L + Balance Sheet generation
17	Reporting	Audit Journal	Fiori `F0997`	Full line-item audit trail
18	Reporting	Compact Document Journal	`S_ALR_87012289`	Compressed view by account
19	Reporting	Disclosure package	Consolidation / BPC	External reporting pack

Reporting Layer — Fiori App Map

flowchart LR
    classDef gl fill:#b8d4f0,stroke:#1565c0
    classDef ar fill:#fff3e0,stroke:#e65100
    classDef ap fill:#e8f5e9,stroke:#2e7d32
    classDef aa fill:#f3e5f5,stroke:#6a1b9a
    classDef co fill:#fff3b0,stroke:#cc9a06

    subgraph GL_APPS["General Ledger Apps"]
        GL1["Display Financial<br>Statements"]
        GL2["Audit Journal<br>(F0997)"]
        GL3["Compact Document<br>Journal"]
        GL4["General Journal<br>Entries"]
        GL5["Manage Posting<br>Periods"]
    end

    subgraph AR_APPS["Accounts Receivable Apps"]
        AR1["Customer Balance<br>Display"]
        AR2["Manage Credit<br>Accounts"]
        AR3["Receivables<br>Management"]
        AR4["Dunning History"]
    end

    subgraph AP_APPS["Accounts Payable Apps"]
        AP1["Vendor Balance<br>Display"]
        AP2["Manage Payment<br>Runs"]
        AP3["Payables<br>Management"]
        AP4["Invoice Approval<br>Workflow"]
    end

    subgraph AA_APPS["Fixed Asset Apps"]
        AA1["Asset Explorer"]
        AA2["Depreciation<br>Forecast"]
        AA3["Asset Balances<br>Report"]
        AA4["Fixed Asset<br>Register"]
    end

    subgraph CO_APPS["Management Accounting Apps"]
        CO1["Project Profitability<br>Overview (F2794)"]
        CO2["Cost Center<br>Actuals Report"]
        CO3["Profit Center<br>Report"]
        CO4["Margin Analysis"]
    end

    GL1 & GL2 & GL3 & GL4 & GL5 --> ACDOCA[("ACDOCA<br>Universal Journal")]
    AR1 & AR2 & AR3 & AR4 --> ACDOCA
    AP1 & AP2 & AP3 & AP4 --> ACDOCA
    AA1 & AA2 & AA3 & AA4 --> ACDOCA
    CO1 & CO2 & CO3 & CO4 --> ACDOCA

    class GL1,GL2,GL3,GL4,GL5 gl
    class AR1,AR2,AR3,AR4 ar
    class AP1,AP2,AP3,AP4 ap
    class AA1,AA2,AA3,AA4 aa
    class CO1,CO2,CO3,CO4 co

Governance & Controls

Governance Framework Overview

flowchart TD
    classDef business fill:#fff3b0,stroke:#cc9a06
    classDef application fill:#b8d4f0,stroke:#1565c0
    classDef integration fill:#e8f5e9,stroke:#2e7d32
    classDef motivation fill:#e6c5f0,stroke:#6a1b9a

    subgraph PREV["Preventive Controls"]
        P1["Credit Limit Check<br>(AR / SD)"]
        P2["Purchase Order<br>Authorization"]
        P3["Segregation of Duties<br>(SoD) — Role Design"]
        P4["Posting Period Lock<br>(OB52)"]
        P5["Asset Class &<br>Capitalization Rules"]
        P6["Tolerance Groups<br>(Invoice Verification)"]
    end

    subgraph DET["Detective Controls"]
        D1["3-Way Match<br>(PO / GR / Invoice)"]
        D2["Subledger to GL<br>Reconciliation"]
        D3["Dunning & Aging<br>Analysis (AR)"]
        D4["Foreign Currency<br>Valuation Review"]
        D5["Intercompany<br>Reconciliation"]
        D6["ACDOCA FI-CO<br>Reconciliation"]
    end

    subgraph CORR["Corrective Controls"]
        C1["Reverse Posting<br>(FB08 / FBRA)"]
        C2["Credit Memo Processing<br>(AR & AP)"]
        C3["Invoice Block<br>Resolution"]
        C4["Reset Clearing &<br>Reprocess"]
        C5["Asset Transfer /<br>Post-Capitalization"]
    end

    subgraph AUDIT["Audit & Transparency"]
        A1["Audit Journal<br>(F0997)"]
        A2["Compact Document<br>Journal"]
        A3["Change Document<br>Logs"]
        A4["Universal Journal<br>Traceability (ACDOCA)"]
        A5["Parallel Ledgers<br>(IFRS / GAAP / Local)"]
    end

    PREV -->|"Upstream<br>enforcement"| DET
    DET -->|"Exception<br>identified"| CORR
    CORR -->|"Corrected posting<br>in ACDOCA"| AUDIT
    PREV -->|"Configuration<br>documented"| AUDIT

    class P1,P2,P3,P4,P5,P6 business
    class D1,D2,D3,D4,D5,D6 application
    class C1,C2,C3,C4,C5 integration
    class A1,A2,A3,A4,A5 motivation

Preventive Controls

Preventive controls in S/4HANA are configuration-enforced — they operate at transaction entry time and cannot be bypassed without deliberate system authorization overrides.

Credit Management (AR)

The credit limit check executes at sales order creation in SD, before any goods movement or billing occurs. Key design decisions:

Parameter	Governance Implication
Credit limit per customer	Set by Finance; enforced by system at SD
Credit check horizon	How far forward open orders count against limit
Automatic block vs. warning	Block requires release authorization — creates audit trail
Credit segment	Allows differentiated limits across business units

Finance sets the limit; Sales cannot unilaterally release a hard credit block. The release authorization must be segregated from the sales order creator.

Purchase Order Authorization (AP)

The purchase requisition and PO release strategy enforces spending authority limits before any liability is created. The 3-way match is the downstream enforcement mechanism — but its effectiveness depends entirely on the PO having been properly authorized upstream. An unauthorized PO that passes 3-way match is still a control failure.

Segregation of Duties

SoD in S/4HANA is enforced through the authorization object framework — role-based access that controls which transactions, company codes, posting keys, and document types a user can execute. Critical SoD conflicts to prevent:

Conflict	Risk
Create vendor master + post invoice	Fictitious vendor fraud
Post invoice + execute payment run	Unauthorized disbursement
Create customer + post credit memo	Revenue manipulation
Post asset acquisition + run depreciation	Asset value manipulation
Post journal entry + approve journal entry	Unsupported manual postings

Posting Period Control

Transaction OB52 controls which fiscal periods are open for posting by account type (A=Assets, D=Customers, K=Vendors, S=GL accounts). Prior periods must be locked immediately after close sign-off — open prior periods are the most common source of restatement risk in SAP environments.

Asset Capitalization Rules

The determination of whether an expenditure is capitalized as an asset or expensed has direct P&L and balance sheet impact. S/4HANA enforces this through:

Asset classes — each linked to specific GL reconciliation accounts; posting to the wrong class posts to the wrong account
Capitalization thresholds — configured per asset class; below-threshold items post to expense accounts automatically
Asset under construction (AuC) — project spend accumulates in AuC until formal capitalization; premature or missed capitalization is a key audit finding

Invoice Tolerance Groups (AP)

Tolerance keys in MM and FI define acceptable variance bands between PO price, GR value, and invoice amount. Invoices outside tolerance are automatically blocked — they cannot be paid until a designated approver resolves the block. This is the primary automated control against overbilling.

Detective Controls

3-Way Match

The cornerstone AP detective control — matching the authorized purchase order, the actual goods receipt, and the vendor invoice before any payment is released.

flowchart LR
    classDef doc fill:#b8d4f0,stroke:#1565c0
    classDef check fill:#e8f5e9,stroke:#2e7d32
    classDef outcome fill:#fff3b0,stroke:#cc9a06

    PO["Purchase Order<br>(Authorized Qty & Price)"]
    GR["Goods Receipt<br>(Actual Qty Delivered)"]
    INV["Vendor Invoice<br>(Billed Qty & Price)"]

    MATCH{"3-Way<br>Match"}
    OK["Invoice Approved<br>for Payment"]
    BLOCK["Invoice Blocked<br>— Tolerance Exceeded"]
    DIFF["Quantity or Price<br>Difference Posted"]

    PO --> MATCH
    GR --> MATCH
    INV --> MATCH
    MATCH -->|"Within tolerance"| OK
    MATCH -->|"Outside tolerance"| BLOCK
    BLOCK -->|"Resolved"| OK
    MATCH -->|"Partial delivery"| DIFF --> BLOCK

    class PO,GR,INV doc
    class MATCH check
    class OK,BLOCK,DIFF outcome

Subledger to GL Reconciliation

Each subledger maintains a reconciliation account on the customer, vendor, or asset master. Every subledger posting automatically updates the corresponding GL reconciliation account — direct manual posting to these accounts is blocked by system design. The reconciliation check (F.03) compares subledger totals against GL account balances. In a correctly configured S/4HANA system running on ACDOCA, this check should always pass — a difference indicates either a configuration error or data corruption and requires immediate investigation.

Dunning & AR Aging

The dunning program identifies overdue receivables and issues tiered notices to customers. From a governance perspective, dunning is a revenue assurance control — systematic tracking of collection risk.

Parameter	Governance Purpose
Dunning levels (1–4+)	Escalating urgency; level 4 typically triggers legal action
Minimum amounts	Avoids dunning for immaterial items
Dunning interest	Contractual penalty calculation
Dunning block	Finance override for disputed items

Foreign Currency Valuation

Open items and GL balances denominated in foreign currency must be revalued at period-end exchange rates. Transaction FAGL_FC_VAL produces unrealized gain/loss postings that reverse at the start of the next period. Failure to run this step results in understated or overstated balance sheet positions — a common audit finding in international entities.

Intercompany Reconciliation

For multi-entity groups, intercompany receivable and payable balances must net to zero before consolidated financial statements can be prepared. Unreconciled intercompany differences are a consolidation blocker and must be resolved before close sign-off.

ACDOCA FI-CO Reconciliation

The Universal Journal should by design keep FI and CO in continuous alignment. The reconciliation report (FINS_RCON) verifies this. Any difference between FI postings and CO postings in ACDOCA indicates a system configuration issue — typically a missing cost element or account assignment — and must be resolved before management reporting is issued.

Corrective Controls

Direct deletion of posted documents is not permitted in S/4HANA. Every correction creates a new document that references the original — the original is never modified or deleted. This is the foundation of the traceability that auditors rely on.

Correction Type	Mechanism	Transaction	Governance Rule
Reverse a GL posting	Full document reversal	`FB08`	Reversal reason code required; original document preserved
Reverse a cleared item	Reset clearing first, then reverse	`FBRA` → `FB08`	Two-step process; both steps logged
Correct an AP invoice	Credit memo from vendor	`MR8M` / `FB65`	Must reference original document
Correct an AR invoice	Credit memo to customer	`FB75`	Requires approval for material amounts
Reclassify an asset	Asset transfer	`ABUMN`	Depreciation recalculated from transfer date
Post-capitalize project spend	Post-capitalization	`ABZE`	Requires capitalization date justification
Correct a CO assignment	Repost CO document	`KB11N`	FI document unchanged; CO corrected only

Audit & Transparency Layer

Audit Journal (Fiori F0997)

The primary audit tool in S/4HANA. Provides 15 filter fields — account, document type, posting date, user, amount range, reference — with full line-item drill-down to the originating document and export to spreadsheet for external audit packages. It replaces and substantially exceeds the legacy Compact Document Journal in flexibility and traceability depth.

Parallel Ledgers

S/4HANA supports multiple accounting principles in parallel within a single system. Each ledger — for example, a leading ledger for IFRS and a non-leading ledger for local GAAP — maintains its own valuations for asset depreciation methods and useful lives, foreign currency translation approaches, revenue recognition timing differences, and lease accounting treatment. A single transaction can produce different financial results under different accounting principles simultaneously; both are stored in ACDOCA and can be reported independently without reconciliation effort.

Universal Journal as Audit Foundation

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100
    classDef uj fill:#b8d4f0,stroke:#1565c0
    classDef audit fill:#e6c5f0,stroke:#6a1b9a

    subgraph ORIG["Originating Events"]
        O1["SD Billing Document"]
        O2["MM Invoice Document"]
        O3["AA Depreciation Run"]
        O4["Manual Journal Entry"]
        O5["Payroll Posting"]
        O6["Intercompany Transfer"]
    end

    subgraph UJ["Universal Journal — ACDOCA"]
        U1["FI Line Items<br>(replaces BSEG)"]
        U2["CO Line Items<br>(replaces COEP)"]
        U3["AA Values<br>(replaces ANEP)"]
        U4["ML Actual Costs<br>(replaces MLCD)"]
        U5["Parallel Ledger<br>Valuations"]
        U6["Profit Center &<br>Segment Attributes"]
    end

    subgraph AUDIT["Audit & Transparency"]
        A1["Audit Journal<br>(F0997)"]
        A2["Compact Document<br>Journal"]
        A3["Change Document<br>Logs (CDHDR/CDPOS)"]
        A4["Document Relationship<br>Browser"]
        A5["Financial Statement<br>Drill-Down"]
        A6["Parallel Ledger<br>Comparison Reports"]
    end

    O1 & O2 & O3 & O4 & O5 & O6 --> U1
    U1 --> U2
    U1 --> U3
    U1 --> U4
    U1 --> U5
    U1 --> U6

    U1 --> A1
    U1 --> A2
    U1 --> A3
    U2 --> A1
    U3 --> A5
    U4 --> A5
    U5 --> A6
    U1 --> A4

    class O1,O2,O3,O4,O5,O6 source
    class U1,U2,U3,U4,U5,U6 uj
    class A1,A2,A3,A4,A5,A6 audit

Full Controls Matrix

Control	Type	Process	SAP Mechanism	Risk Mitigated
Credit limit check	Preventive	AR / OtC	Credit Management (FI-AR-CR)	Bad debt, revenue loss
SoD — vendor master + invoice	Preventive	AP / PtP	Authorization objects	Fictitious vendor fraud
SoD — invoice + payment	Preventive	AP / PtP	Authorization objects	Unauthorized disbursement
SoD — journal entry + approval	Preventive	GL / RtR	Authorization objects	Unsupported manual postings
PO release strategy	Preventive	AP / PtP	MM release strategy	Unauthorized spending
Asset capitalization threshold	Preventive	AA / AtR	Asset class configuration	P&L misstatement
Invoice tolerance groups	Preventive	AP / PtP	MM / FI tolerance keys	Overbilling / underpayment
Posting period lock	Preventive	GL / RtR	`OB52`	Prior period manipulation
3-way match	Detective	AP / PtP	MIRO automatic match	Invoice fraud, overbilling
Subledger ↔ GL reconciliation	Detective	GL / All	`F.03` / ACDOCA	Posting integrity
Dunning & AR aging	Detective	AR / OtC	Dunning program	Collection risk, bad debt
Foreign currency valuation	Detective	GL / RtR	`FAGL_FC_VAL`	Balance sheet misstatement
Intercompany reconciliation	Detective	GL / RtR	`FBICR`	Consolidation errors
ACDOCA FI-CO reconciliation	Detective	CO / RtR	`FINS_RCON`	Management reporting integrity
Document reversal	Corrective	GL / All	`FB08`	Error correction with audit trail
Reset clearing & reverse	Corrective	AR / AP	`FBRA` → `FB08`	Clearing error correction
Credit memo — AP	Corrective	AP / PtP	`MR8M` / `FB65`	Vendor overbilling correction
Credit memo — AR	Corrective	AR / OtC	`FB75`	Customer billing correction
Asset transfer / reclassification	Corrective	AA / AtR	`ABUMN`	Asset misclassification
Audit Journal	Audit	All	Fiori F0997	External audit evidence
Change document logs	Audit	All	`CDHDR` / `CDPOS`	Master data manipulation
Parallel ledger reporting	Audit	GL / RtR	ACDOCA ledger filter	Multi-GAAP compliance
Document Relationship Browser	Audit	All	Fiori / `FB03`	End-to-end traceability

Recommendation & Conclusion

Four Control Design Principles for S/4HANA

Principle 1 — Upstream process quality determines downstream financial integrity. The majority of FI postings are generated automatically by upstream processes in SD, MM, HR, and PP. A well-configured 3-way match catches overbilling — but only if the PO was correctly authorized in the first place. Controls must be designed end-to-end across the value chain, not just within the FI module boundary. Finance organizations that treat their S/4HANA implementation as a pure accounting project will consistently find that their most persistent audit findings originate in procurement, logistics, and HR — not in FI itself.

Principle 2 — Configuration IS control. In S/4HANA, the distinction between a system configuration parameter and an internal control is narrow. Tolerance groups, posting period variants, asset class assignments, credit limit rules, and SoD role designs are all controls — expressed as configuration rather than procedural policy. Configuration change management is therefore audit-relevant and must be governed with the same rigor as policy changes. A transport that modifies a tolerance key or opens a closed posting period is a control change, not a technical housekeeping item.

Principle 3 — The audit trail is structural, not supplementary. ACDOCA’s architecture means every posted document is permanently traceable to its originating business event. This is not a reporting feature — it is a property of the data model. Audit evidence is always available, always current, and always reconciled to reported figures. Organizations that recognize this use it to dramatically compress audit cycles, replacing the traditional evidence-gathering phase with real-time drill-through from reported balances to source documents.

Principle 4 — Parallel ledgers require parallel control coverage. Where an organization operates under multiple accounting principles — IFRS and local GAAP being the most common configuration — each ledger requires its own control review. A posting that is correctly handled under IFRS may produce an incorrect result under local GAAP if the ledger-specific configuration for depreciation keys, currency translation methods, or revenue recognition rules has not been independently validated. The availability of parallel ledgers in ACDOCA is an architectural strength; it becomes a governance liability if the non-leading ledger configurations are treated as secondary concerns during implementation.

Process Index

Process	BPMN Lanes	Key Tables	Key Transactions	Fiori Apps
Order-to-Cash (AR)	Customer / SD / Logistics / FI-AR	BSID, BSAD, ACDOCA	`VF01`, `F-28`, `F150`	Customer Balance, Receivables Mgmt
Purchase-to-Pay (AP)	Vendor / Procurement / WH / IV / FI-AP	BSIK, BSAK, ACDOCA	`MIRO`, `F110`, `MR8M`	Vendor Balance, Payment Runs
Acquire-to-Retire (AA)	Requestor / AA / GL	ANEP, ANLC, ACDOCA	`AS01`, `AFAB`, `ABAVN`	Asset Explorer, Fixed Asset Register
Record-to-Report (GL)	GL / CO / Reporting	ACDOCA, BKPF	`FB50`, `F.01`, `FAGL_FC_VAL`	Audit Journal, Financial Statements
CO Allocations	CO / Reporting	ACDOCA, COSS	`KSU5`, `KEU5`, `KSII`	Margin Analysis, Cost Center Actuals

Closing Perspective

The Universal Journal is the most consequential structural change in the history of SAP financial accounting. It eliminates the reconciliation burden that consumed a disproportionate share of finance team capacity in ECC environments, and it makes real-time, drill-through financial reporting a platform capability rather than a BI project. But its value is only realized if the upstream processes that feed it — order management, procurement, asset management, payroll — are governed with the same discipline as the accounting processes themselves.

The organizations that extract the most from S/4HANA’s financial accounting architecture are those that treat the go-live not as the end of an implementation project but as the beginning of a continuous controls improvement program — one where configuration changes are governed, upstream data quality is monitored, and the audit trail that ACDOCA provides is actively used to shorten close cycles, accelerate audit responses, and give finance leadership the real-time visibility the platform is designed to deliver.

来源说明：本文翻译/整理自 docs.sajivfrancis.com，作者 Sajiv Francis。原文链接保留，版权归原作者所有。