Design and Implementation of a Reconciliation System for Meituan Delivery Settlement

Background

With the rapid growth of Meituan's delivery business, the daily order volume has reached tens of millions and the daily settlement amount exceeds tens of millions of yuan. Ensuring the stability of the settlement system while guaranteeing fund safety has become a core challenge.

The delivery settlement business has several characteristics:

Multiple scenarios: dedicated delivery, crowdsourced delivery, express delivery, errands, external orders, etc., with various settlement scenes such as subsidies, promotions, penalties, food loss, tips, insurance, and integration with more than ten external systems.

Long processing chain: pricing, accounting, bill aggregation, payment, and other steps.

Huge order volume: daily orders have reached the ten‑million level.

These factors make the system prone to consistency problems, which account for about 70% of the issues observed since the system’s inception.

Causes of consistency problems

Improper idempotency and concurrency control.

Infrastructure failures such as network, database, or message‑queue outages.

Other code bugs.

Given the massive financial impact of each inconsistency, solving consistency problems is essential for fund safety. The industry widely discusses strong consistency protocols (two‑phase commit, three‑phase commit, TCC) and eventual consistency mechanisms (active polling, asynchronous guarantees, reliable messaging, transactional messages).

Definition of reconciliation

Reconciliation originally referred to accounting verification. With the rise of internet finance and e‑commerce, it expanded to cross‑system data verification, covering both information flow and fund flow. In a broad sense, any cross‑system data check is a reconciliation.

Reconciliation system design ideas

The system is divided into three stages: data preparation, data verification, and error handling (also called “balancing”).

Data preparation

The goal is to ingest all data required for reconciliation into a unified data pool. Two main objectives are:

Provide diversified ingestion mechanisms for different external systems (pull, push via ETL, file upload).

Normalize external data into a unified format for storage.

Data push is preferred because it reduces manual effort and decouples the settlement side from external data formats.

Data verification (checking)

The core of reconciliation is to discover inconsistent data. The verification aims at two metrics: coverage and accuracy. The process is split into five steps (illustrated in the diagram).

Problem types are categorized into three:

Missing settlement (data exists on the source side but not on the target side).

Duplicate settlement (the same transaction is settled multiple times).

Incorrect settlement (mismatched amount or status).

Reconciliation methods include:

One‑way reconciliation: use one side as the reference.

Two‑way reconciliation: both sides serve as references, providing more comprehensive detection.

Granularity can be:

Detail‑level reconciliation – compare each record, enabling precise problem location.

Aggregate‑level reconciliation – compare totals, simpler but cannot pinpoint specific records.

Reconciliation templates (fixed or custom) are provided to cover various scenarios.

Timing of reconciliation

Two timing modes are used:

Offline reconciliation – periodic (e.g., T+1) batch processing, suitable for most scenarios.

Online reconciliation – real‑time or near‑real‑time checks embedded in the settlement flow. Real‑time can intercept problematic transactions; near‑real‑time runs asynchronously.

In practice, offline reconciliation is the primary approach, with online checks applied where latency requirements are strict.

Error handling (balancing)

Detected inconsistencies are recorded in a unified error‑record model containing fields such as reconciliation scenario, batch ID, data source, error type, and processing status. A scheduled job re‑examines each error record; if the issue is confirmed, the system either automatically repairs it (for known patterns) or raises an alarm for manual intervention. A playback tool allows operators to replay the entire settlement lifecycle and apply one‑click fixes.

Overall architecture

The reconciliation system consists of three modules that collaborate to cover data preparation, verification, and error handling:

Offline reconciliation platform – data ingestion, management, and execution layers.

Online reconciliation platform – management and execution layers for real‑time/near‑real‑time checks.

Balancing center – unified error record storage and processing.

Each module follows the design principles described above, ensuring full‑link coverage, high accuracy, and efficient problem resolution.

Conclusion and outlook

After implementation, the system provides comprehensive reconciliation across all nodes, guaranteeing fund safety and data consistency. Future work will focus on expanding coverage, increasing automation in error handling, and reducing integration cost for new business scenarios.