DingTalk Reimbursement Monthly Settlement to Kingdee Payment Voucher: A Single-Strategy Sync Tutorial

What This Strategy Solves

A group runs daily expense reimbursements through DingTalk approval. At the monthly settlement point, finance needs to turn approved monthly-settlement reimbursement records into Kingdee payment vouchers and post them to the general ledger. Manual entry is slow and frequently causes mismatches in amount, applicant, and payee account. We used Qeasy Data Integration Platform to build a single strategy: pull monthly-settlement reimbursement records from DingTalk on a schedule, validate them, and write Kingdee payment vouchers so the approval result and the GL voucher form a closed loop.

Data Flow and Field Mapping

The pipeline is three-stage: DingTalk reimbursement (source) → Qeasy middle layer (orchestration & mapping) → Kingdee payment voucher (target).

On the source side we only fetch records that are approved and tagged as "monthly settlement," so drafts still in approval do not leak downstream. The middle layer handles encoding, amount, currency, and payment-method normalization, then pushes to Kingdee.

Note: line items (expense entries) outside the header must be aggregated in the middle layer by "expense code + department + project" before being written into the Kingdee body. Otherwise one reimbursement may be split into multiple payment vouchers in Kingdee.

How to Configure It on Qeasy

In Qeasy Integration Platform, this strategy corresponds to one "integration solution." Configure it roughly as follows:

1. Source data source: pick the DingTalk reimbursement API; filter by monthly-settlement flag and approval status.
2. Target data source: the Kingdee payment-voucher save API, using the customer's public-cloud tenant.
3. Field mapping: use the visual mapping canvas. Where a DingTalk text field does not match a Kingdee enum, centralize the conversion in an "encoding mapping" component. For example, when DingTalk says "bank transfer" but Kingdee needs an enum value, put all enums in one mapping table rather than scattered across strategy scripts — a common pattern we see across Qeasy customers: centralized encoding mapping.
4. Script logic: amount validation, applicant/payee consistency check, and currency normalization are all done in middle-layer scripts. Add an idempotency key (DingTalk doc number + monthly batch number) to prevent duplicate payment vouchers on rerun.
5. Write-back: write the Kingdee document number back into the DingTalk reimbursement's extension field so finance can reconcile on both sides.

Implementation Steps

We recommend three phases, to avoid dumping dirty data into Kingdee from a cold start.

• Phase 1: Incremental baseline (manual trigger once) Pick a natural month as the baseline on the DingTalk side, trigger one sync manually, and confirm the mapping is correct and Kingdee saves properly before letting go. Record the document numbers produced by the baseline run as anchors for later verification.

• Phase 2: Full trigger (rerun by monthly batch) On the monthly settlement day, after finance confirms "monthly settlement" in DingTalk, a one-shot schedule pulls the whole batch and produces payment vouchers. Note that a full rerun must rely on the idempotency key: skip already-succeeded records, fill in the missing ones.

• Phase 3: Schedule frequency (daily incremental + monthly batch) No daily schedule. On the monthly settlement day, the DingTalk approval flow fires an event; Qeasy listens to it and starts the batch sync. Another common pattern among Qeasy customers is "incremental and full dual track": nothing runs daily, a single full run on the settlement day, isolated by the idempotency key.

Schedule frequency suggestion: once per month, tied to the DingTalk settlement cadence; retry 3 times on failure with 5/15/30 minute intervals to avoid repeated submissions during the Kingdee lock window.

Pitfalls We Hit in the Field

1. Payment-method text does not match enums. DingTalk uses colloquial descriptions like "corporate transfer," "cash," "offset loan," while Kingdee uses enums. A typical mistake is putting an if-else in every strategy. The right way is a single mapping table — when a new payment method is added, you change one place.

2. Applicant ≠ payee is overlooked. Some reimbursements are employee prepayments where the payee is a vendor or external party. We did not handle this early on, so prepaid payments got booked as employee loans and reconciliation failed. The robust approach is to explicitly check in the middle layer: when the payee ID is empty, fall back to the applicant's employee.

3. Rerun creates duplicate Kingdee payment vouchers. If the schedule fails on settlement day and someone reruns manually without an idempotency key, duplicates get submitted. The robust approach is: use the DingTalk reimbursement number as the external document number in Kingdee, enable "external-doc-number duplicate check" on the Kingdee side, and add idempotency validation on the platform side as a second safety net.

4. Decimal and rounding differences. DingTalk amounts may keep sub-cent precision; Kingdee payment vouchers only accept two decimals, and inconsistent rounding leaves a few cents of mismatch. We recommend normalizing to "round half up to cent" in the middle layer and carrying the original value in the explanation.

5. No failure-rollback strategy. When one record fails mid-way, some lines get into Kingdee but the header does not, making it hard to track. Configure "whole-document transaction" on Qeasy: if the header fails, the body is not written; failed records go to a pending list for manual handling by finance rather than endless retries.

When It Fits and When It Does Not

Fits: companies whose reimbursement approval runs on DingTalk, whose bookkeeping runs on Kingdee, and who settle expenses monthly; volume within the settlement window is manageable. Does not fit: high-frequency real-time payments with zero tolerance for reconciliation delay; or companies whose DingTalk approval flow is still messy with inconsistent status fields — in that case, clean up the source first, do not rush into integration.