Automatic Account Determination
MM / P2Parchitect

MM Account Determination Part 4: Architecture for Multi-Entity, Multi-System Landscapes

Key takeaway

Design account determination for many company codes and systems: shared vs separate charts of accounts, grouping code strategy, harmonized valuation classes, central governance of OBYC changes, transport and test discipline, and consistency with group reporting in S/4HANA.

Explanation

📌 KEY POINTS
✅ A common operational chart of accounts enables one OBYC design across company codes.

✅ Grouping codes separate only where accounting requirements differ.

✅ Harmonized valuation classes make group inventory reporting comparable.

✅ Central governance: change requests, finance approval, transports and regression tests.

⚠️ Local changes directly in systems create drift between entities and systems.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE

Part 3 covered keys and modifiers. Now architecture.

━━━━━━━━━━━━━━━━━━━━
▶ 1. CHART OF ACCOUNTS

  • Common operational chart; local requirements via alternative accounts.

━━━━━━━━━━━━━━━━━━━━
▶ 2. GROUPING STRATEGY

  • Minimal set of grouping codes with documented reasons.

━━━━━━━━━━━━━━━━━━━━
▶ 3. VALUATION CLASSES

  • Global list aligned with group accounts.

━━━━━━━━━━━━━━━━━━━━
▶ 4. GOVERNANCE

  • Account matrix owned by finance; change process; transports.

━━━━━━━━━━━━━━━━━━━━
▶ 5. MULTI-SYSTEM CONSISTENCY

  • Template comparison across systems; regression tests.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

  1. Define global account matrix.
  2. Map local exceptions.
  3. Set change and test process.

✅ CHECKPOINT: all entities follow one matrix, and exceptions are documented.

Code example

ABAP Code
===== STEP 1: design =====Operational chart INT for all company codes | grouping codes: 0001 standard, 0002 special legal requirementGlobal valuation classes 3000-3999 raw, 7900-7999 finished ===== STEP 2: governance =====Change request → finance approval → configuration in dev → transport → regression tests (101/201/551/701/IR) ===== STEP 3: consistency =====Compare OBYC across systems | template documentation

Real project scenario

A global manufacturer was consolidating several regional systems; each used different valuation classes and OBYC entries, making group inventory reports unreliable. A global account matrix, harmonized classes and a central change board aligned postings during migration.

Common mistakes

  • Local charts per company code.
  • Too many grouping codes.
  • Direct changes in production.
  • No regression tests.
  • Undocumented exceptions.

Best practices

  • Common operational chart.
  • Minimal grouping codes.
  • Central account matrix.
  • Transport discipline.
  • Regression testing.

Interview angle

Questions: "How do you design account determination globally?", "When use multiple grouping codes?", "How do you govern OBYC?"
Strong answer: chart of accounts, grouping strategy, harmonized classes, governance and testing, consistency.

Practice this lesson

Quick check

1. What enables a single OBYC design across many company codes?

2. What is the best practice for OBYC changes in a multi-entity landscape?

3. Why harmonize valuation classes across a group?

Interview questions

1. From an architect's perspective, what authorization design principles should govern who can post directly to GR/IR clearing accounts versus who can only clear them through standard MM transactions like MIRO or MIGO, especially in a landscape integrated with PP order settlements?

Answer it in your own words first, then compare.

2. In a Central Procurement (SAP S/4HANA hub) landscape sourcing requisitions from multiple connected ECC/S4 backend systems, how does account assignment get resolved when the requisition originates in a backend system but the PO is created centrally?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics