Syncing DingTalk Administrative Reimbursements to Kingdee Payment Vouchers: A Single-Strategy Tutorial
What This Strategy Solves
In many enterprises, administrative expenses are reimbursed through DingTalk while financial bookkeeping lives in Kingdee Cloud. The two systems don't talk to each other, so finance teams manually re-enter payment vouchers every month — slow and error-prone. This strategy automatically turns approved administrative reimbursement forms in DingTalk into Kingdee Cloud payment vouchers, closing the loop from reimbursement to accounting.
Data Flow and Field Mapping
The pipeline is: DingTalk reimbursement (administrative) → Qeasy integration platform → Kingdee Cloud payment voucher. The middle layer handles three jobs: extraction, cleansing, and assembly.
Key field mapping (administrative reimbursement → payment voucher):
| Dimension | DingTalk Field | Kingdee Field | Mapping Notes |
|---|---|---|---|
| Document No. | Reimbursement ID | Voucher No. | Pass through; add prefix to prevent duplicates |
| Applicant | Employee name | Applicant / Payee | Resolve via employee directory |
| Amount | Approved amount | Payment amount | Match tax handling with Kingdee |
| Expense item | Expense type | Expense account | Maintain centralized mapping table |
| Receiving account | Last 4 of card no. | Payee account | Store full value in middle layer |
| Approval time | Approval completion | Business date | Use approval completion |
How to Configure in Qeasy
We recommend splitting this strategy into three visual stages: source extraction, transformation, and target write.
- Source extraction: Use the DingTalk reimbursement API, filter by "administrative" type, and only fetch records in "approved" status. The incremental cursor should use approval completion time, with the initial value set to 00:00 of the day before go-live.
- Transformation layer: In Qeasy, maintain an "expense type → Kingdee account" mapping table. This is critical — a common pattern among Qeasy customers is centralized mapping management, where DingTalk expense types, Kingdee accounts, and payment purposes are all consolidated in one place so future maintenance only touches one spot.
- Target write: Call Kingdee Cloud's payment voucher save API. We recommend saving first as "draft" then "submit for review" to avoid rolling back an entire batch on a single failure.
Implementation Steps
We typically split the rollout into three phases:
- Incremental baseline: On go-live day, push all administrative reimbursements approved in the past 7 days into Kingdee as the initial baseline. This runs as a full trigger, but disable Kingdee's auto-audit first to avoid mass posting of historical data.
- Routine scheduling: The strategy runs on a 15-minute polling cycle, combined with webhook-triggered real-time sync from DingTalk, achieving "push immediately after approval." Both can coexist in Qeasy, forming a hybrid of incremental and full sync.
- Exception handling: Failed writes go to Qeasy's exception queue, categorized by error code — missing mapping, header validation failure, network timeout — and handled separately, not retried in bulk.
Pitfalls and Lessons Learned
- Expense type mappings were initially scattered across multiple Excel files. When Kingdee accounts changed, two entries were missed and reconciliation diverged for three months before being noticed. The safe approach is to keep the mapping table in only one place in Qeasy's transformation layer.
- Mixing DingTalk's approval completion time and submission time caused Kingdee payment vouchers' business date to be a week earlier than the actual reimbursement. A typical mistake is using submission time as business date — it should always be approval completion time.
- During the full backfill, Kingdee had auto-audit enabled, and hundreds of vouchers flooded into pending payment, prompting an immediate call from finance. Easy to miss here — auto-audit must be disabled during the full phase.
- Employees can change the "administrative" tag in DingTalk themselves, causing missed pushes. The reliable approach is to double-validate by expense type code on the source side, not just trust the tag.
- Storing only the last four digits of the receiving account wouldn't land in Kingdee. The fix is to store full values in the middle layer and truncate according to Kingdee rules when writing.
Suitable and Unsuitable Scenarios
Suitable: Reimbursement approval in DingTalk, accounting in Kingdee, high share of administrative expenses, and a well-defined expense account structure. Not suitable: Reimbursement still handled offline, Kingdee requires complex multi-level approval, or DingTalk reimbursement types change so frequently that a stable mapping cannot be maintained.