Designing a Robust Order-to-Payment Settlement Module: Conceptual Model & Key Practices

Introduction

In the order‑to‑payment flow, integrating complex financial settlement systems is common. This guide presents a typical settlement module design using a conceptual model to quickly grasp the involved entities, their relationships, and the main design considerations.

Settlement Scenarios

Core Process Diagram:

Terminology and Core Scenarios:

Receivable scenario: From the enterprise’s viewpoint, it defines how much the company should collect from customers. Examples include sales settlement sheets and receivable adjustment sheets.

Payable scenario: Documents that specify how much the enterprise should pay to customers, such as discounts/allowances and payment vouchers.

Collection scenario: A collection request matches cash‑flow records and ultimately generates a collection receipt.

Accounting entry scenario: Completed documents generate corresponding (positive or reverse) ledger entries that modify various account balances.

ERP posting scenario: Completed documents produce ledger entries that adjust account amounts (e.g., receivable net amount) and must be posted in the ERP system. Posting types include receivable posting, collection posting, and credit posting.

ERP write‑off posting scenario: Receivable documents are offset against payable or collection documents (positive/negative cancellation). This is divided into collection write‑off (involving a collection receipt) and credit write‑off. Depending on business complexity, there may be automatic or manual, partial or full, and reversal write‑off scenarios.

Invoicing scenario: In China, typical invoices are red‑letter (negative, credit) and blue‑letter (positive, revenue). Overseas, commercial invoices (CI) and credit notes (CN) are also used.

Settlement Conceptual Model Design

Design Highlights:

Application documents usually carry supplemental information collection and approval processes, whereas completed documents represent the final, voucher‑level records. Some scenarios generate completed documents directly, such as sales settlement sheets pushed from an order system.

Completed documents create ledger entries that modify account balances; an account is uniquely identified by business client + legal entity + accounting entity + currency.

Depending on the scenario, not only completed documents but also application documents may trigger ledger movements. Application‑driven movements affect “in‑transit” accounts, and when the application converts to a completed document, the movement occurs in two steps: first clearing the in‑transit amount, then adjusting the receivable net‑account.

Because ERP systems often do not return posting results immediately, an ERP posting status table is needed to centralise the status of various documents. A scheduled task periodically queries and updates these statuses.

After a completed document is successfully posted in ERP, it generates either a forward receivable or a reverse receivable write‑off document. Both types share the same account dimension and follow configurable write‑off rules (e.g., FIFO or overdue‑first).

Invoice application documents are typically created after supplemental information collection and approval, such as uploading a red‑letter information form for red‑invoice issuance.

Invoicing has two main patterns: (a) automatic invoicing triggered after a completed document is generated, with results synced back; (b) manual invoicing initiated by users after a completed document, which may involve batch invoicing and requires performance‑aware design.

The core business of the settlement module revolves around various movements, postings, and invoicing processes. To implement this efficiently, a simplified ultimate model—receivable adjustment application + receivable adjustment document—targets adjustments to the receivable net‑account and can be driven by dynamic configuration tables to support diverse scenarios.

Conclusion

This design provides a reference model for a typical settlement module within an order‑to‑payment flow. The conceptual model helps quickly understand the overall architecture, while actual implementations should refine attributes and logic based on specific business requirements.