KB-212 – Accounting Engine Architecture

Knowledge Base ID: KB-212
Chapter: 12 - Accounting Dimensions & C_ValidCombination
Project: BLACK ERP
Version: 1.2
Status: Draft
Last Updated: 2026-06-26
Applies To: ADempiere 3.9.4

---

Purpose

This chapter explains one of the most important architectural concepts in the ADempiere Accounting Engine: the Accounting Combination.

Instead of storing individual accounting dimensions throughout the system, ADempiere centralizes them in a single object represented by the C_ValidCombination table and the MAccount model.

Understanding this design is essential before studying persistence, transaction management and posting internals.

---

The Problem

A General Ledger account is rarely just an account number.

A complete accounting entry may include:

• Natural Account
• Organization
• Business Partner
• Product
• Project
• Campaign
• Activity
• Sub Account
• User Elements

If every accounting table stored all these fields independently, the database would contain massive duplication.

---

ADempiere Solution

Instead of storing every accounting dimension repeatedly, ADempiere stores a single identifier.

Conceptually:

FactLine

↓

Account_ID

↓

C_ValidCombination

That identifier references a complete accounting combination.

---

What is C_ValidCombination?

C_ValidCombination represents a fully qualified accounting combination.

Conceptually:

C_ValidCombination

├── Account
├── Organization
├── Business Partner
├── Product
├── Project
├── Campaign
├── Activity
├── Sub Account
├── User Element 1
└── User Element 2

A single record uniquely identifies every accounting dimension required for posting.

---

Architectural Position

The Accounting Engine uses the following hierarchy.

Business Document

↓

Doc

↓

MAccount

↓

C_ValidCombination

↓

FactLine

↓

FACT_ACCT

Notice that FactLine never stores an account number directly.

It stores a reference to a valid accounting combination.

---

Why It Exists

The design provides several important benefits.

Eliminate Redundancy

Instead of:

FactLine

Account
Organization
Project
Campaign
Activity
...

ADempiere stores:

FactLine

↓

Account_ID

All remaining dimensions are obtained through the referenced combination.

---

Data Consistency

Every document referencing the same accounting combination uses exactly the same accounting dimensions.

This prevents inconsistent journal entries.

---

Performance

Thousands of accounting entries may reference the same C_ValidCombination.

Instead of duplicating data, ADempiere reuses existing combinations.

Conceptually:

FactLine A

↓

1000087

FactLine B

↓

1000087

FactLine C

↓

1000087

Only one accounting combination exists in the database.

---

The Role of MAccount

The Java representation of C_ValidCombination is:

org.compiere.model.MAccount

The Posting Engine never manipulates database rows directly.

Instead, it works with MAccount objects.

Conceptually:

Database

↓

C_ValidCombination

↓

MAccount

↓

Accounting Engine

---

MAccount Responsibilities

MAccount encapsulates the complete accounting combination.

Typical responsibilities include:

• Loading combinations
• Creating new combinations
• Reusing existing combinations
• Cache management
• Validation support

The Accounting Engine never needs to know how combinations are stored internally.

---

Relationship with FactLine

During posting:

Doc.getAccount()

↓

MAccount

↓

Fact.createLine()

↓

FactLine.setAccount()

The FactLine receives the complete MAccount object.

It then expands its individual dimensions before persistence.

---

Relationship with Accounting Metadata

The previous chapters explained how accounting metadata determines which account should be used.

This chapter introduces the object that represents the result.

Conceptually:

Accounting Metadata

↓

getValidCombinationId()

↓

C_ValidCombination

↓

MAccount

↓

FactLine

Metadata answers:

Which accounting combination should be used?

MAccount answers:

Here is that complete accounting combination.

---

BLACK ERP Example

The Mexican VAT Cash Basis implementation uses this mechanism without introducing special handling.

Example:

IVA Acreditable Pagado

↓

Account 118.001

↓

C_ValidCombination

↓

MAccount

↓

FactLine

The posting engine never hardcodes account 118.001.

Instead, it resolves the corresponding accounting combination and reuses the existing infrastructure.

---

Why This Design Matters

This architecture allows the Accounting Engine to support:

• Multiple Organizations
• Multiple Products
• Multiple Projects
• Parallel Accounting Schemas
• Flexible Accounting Dimensions

without changing the posting logic.

Only the accounting combinations change.

The Posting Engine remains generic.

---

Engineering Principles

Several important architectural principles become visible.

• Accounting dimensions are centralized.
• Business documents never manipulate dimensions directly.
• MAccount abstracts database persistence.
• Accounting combinations are reusable.
• FactLine references combinations rather than rebuilding them.
• Posting remains metadata-driven.

---

Key Takeaways

• C_ValidCombination stores complete accounting combinations.
• MAccount is the Java representation of those combinations.
• Accounting entries reference combinations instead of individual dimensions.
• Reusing combinations improves consistency and performance.
• The Posting Engine remains independent of database implementation details.

---

Next Chapter

Chapter 13 explores how MAccount, PO, save(), saveEx(), transactions and persistence work together to store accounting entries inside FACT_ACCT.

---

Revision History

Version	Date	Description
1.2	2026-06-26	Added Accounting Dimensions, C_ValidCombination architecture and MAccount relationship.