Reconciliation and Bill Download Handbook: End-of-Day Matching, Discrepancies, and Retention

Reconciliation and Bill Download Handbook: End-of-Day Matching, Discrepancies, and Retention

A working payment integration only proves money can be collected; it does not prove the books can be closed. Finance needs reports, revenue confirmation and performance figures, and all of that rests on reconciliation. It is also the step technical teams most often underestimate, because it never sits in a prominent place in the requirements document, yet when it breaks, finance stops entirely.

This article is structured as a handbook in operating order: when to pull bills, how to compare, what to do about differences, and what evidence to keep. For integration-side detail, see payment transaction flow basics, and for refunds, the refund and settlement operations handbook.

1. Why Reconciliation Is Mandatory

Three reasons, none optional.

First, callbacks get lost. Network jitter, service restarts and endpoint timeouts all cause missed asynchronous notifications. A system that trusts callbacks alone will accumulate cases of money received but state unchanged.

Second, amounts go wrong. Unit conversion, discount allocation and stacked partial refunds all introduce error. Reconciliation is the only systematic way to detect it.

Third, finance needs closure. Revenue recognition, cost accounting and tax filing all require verifiable ledger evidence, not a status field in an application database.

2. Distinguish the Three Statement Types

Many teams reconcile only transaction statements and then find the account balance never matches, because fees are deducted separately, so settlement amounts do not equal transaction amounts. Only the fund statement explains why total transactions differ from cash received.

3. When Bills Are Generated and How to Fetch Them

Domestic channel bills are generally generated T+1 for the previous day, not available in real time. That means:

• Full reconciliation for the current day is impossible; only real-time checks based on callbacks and queries work;
• Complete reconciliation must be a T+1 scheduled job, usually run between early morning and late morning;
• Holiday generation rules vary by channel, and some defer.

There are two retrieval methods: manual download from a portal and automated request through an interface. Production must use the automated path, with manual download reserved for emergencies. WeChat Pay requires requesting a trade bill to obtain a download URL and then fetching the file, Alipay exposes a download link through a bill query endpoint, and UnionPay typically provides files by date on a file server. Files are usually CSV archives that must be extracted and parsed.

One detail that must not be missed: download links expire, so they must be re-requested. A scheduled job should request and download within the same execution rather than storing a link for later.

4. Three-Layer Matching

Do not begin with a line-by-line comparison. Converge at coarse granularity first to localize the problem quickly.

Layer one: counts and totals. Local success count versus bill count, local amount sum versus bill amount sum. If this layer disagrees, there is a structural difference such as lost orders, duplicates, or mixed channels, and deeper comparison is pointless.

Layer two: record-level matching. Join on merchant order number and classify results into three buckets:

• Local only: either locally judged successful incorrectly, or the order went through another channel;
• Bill only: the classic missed order, a prime candidate for a lost callback;
• Both present but amounts differ: unit conversion or discount allocation error.

Layer three: state and timing checks. For matched records, verify transaction time, payment method and fees. This layer catches subtler problems such as channel-side amendments or currency effects.

5. Handling the Five Discrepancy Types

Overage (bill has it, local does not): first check for a missed callback. Query the order actively, and if payment succeeded, post the entry and record the missed-order cause. If the query shows no such transaction, suspect an order number mismatch caused by case or whitespace differences and fix the mapping.

Shortage (local has it, bill does not): a local success with no channel record is serious, possibly a forged callback or a local misjudgment. Freeze the order immediately, inspect the raw callback payload and verification result, and contact the channel if needed.

Amount mismatch: most often a unit error mixing yuan and cents, or discount allocation. Fix by storing amounts as integer minor units and asserting before insert.

Duplicate posting: the same order processed twice. Root causes are missing callback idempotency or a race between the fallback posting job and the callback. A unique index is the fix.

State mismatch: local shows success while the channel shows closed, or the reverse. Usually a close-versus-pay race. Handle by querying immediately after a failed close and correcting local state to match the channel.

Every discrepancy belongs in a ledger: order number, discrepancy type, amount involved, detection time, cause, action taken, owner, and closure time. That ledger is the only basis for spotting trends.

6. Troubleshooting Order When Reconciliation Fails

When the job reports an imbalance, check in this order to save most of the time:

1. Time range correctness, including time zone, day boundary, and whether deferred holiday data was included;
2. File completeness, since extraction failures and empty downloads are common;
3. Channel coverage, because omitting one channel's bill is the single most frequent cause in multi-channel setups;
4. Refund deduction, since transaction statements usually exclude refunds and need separate matching;
5. Fee treatment, whether figures are gross or net of fees;
6. Test orders, which permanently distort results if any exist in production.

7. Retention and Audit

Reconciliation artifacts are financial records and require long-term retention: raw bill files, parsed ledgers, discrepancy logs and handling records. Retention periods follow finance and tax requirements, typically no shorter than the statutory retention period for accounting archives, and should be confirmed against current local requirements.

Three retention rules: raw files stay unmodified, with parsed output stored separately and originals read-only; results are traceable by version, with every reconciliation run carrying a job ID and execution time; and access is controlled, since bills contain transaction detail and are sensitive data.

8. A Reference End-of-Day Sequence

An executable checklist in time order:

1. After midnight, trigger the scheduled job to request and download all channel bills.
2. Extract, parse and normalize fields, unifying amount units and time formats.
3. Run the layer-one count and total check; alert and stop on imbalance.
4. Run layer-two record matching and produce the discrepancy list.
5. Query discrepancies, auto-correcting what can be corrected and queuing the rest for manual review.
6. Generate the reconciliation report and push it to finance and business owners.
7. Work the discrepancy ledger to same-day closure or provide an expected closure date.
8. Archive raw bills and the reconciliation result.

Multi-channel setups add another layer of reconciliation complexity, covered in aggregate payment and the service provider model. For automated invoicing and bill generation, see automated invoice and billing generation. For the WeChat Pay bill endpoints, see WeChat Pay APIv3 integration in practice. More options are collected under the Payment category.

Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow pay.weixin.qq.com and related official documentation and contract terms.