From Reconciliation Results to ERP Vouchers: The Last Mile of Financial Data
Why the Last Mile Often Breaks
Discrepancies are cleared in the reconciliation system, yet finance still keys vouchers by hand — a common reality. The breakpoint: between the business language of reconciliation results (platform, store, accounting item) and the financial language of the ERP (accounts, auxiliary dimensions, voucher types) there is no deterministic mapping. Until that layer exists, month-end always stalls at "typing vouchers from Excel."
The Data Flow from Results to Vouchers
First, extract closed reconciliation results by platform × store × settlement cycle, with revenue, each fee and refunds separated. Then map: accounting items to GL accounts plus auxiliary dimensions (store to department, platform to customer or business partner). Then generate documents — receivables and receipts (or expense documents) in the ERP. Finally, once documents are approved, voucher templates produce the general-ledger entries.
A Reference Account Mapping
Merchandise receivable debits Accounts Receivable – XX Platform and credits Main Business Revenue plus Output VAT. When the platform payout arrives, debit Bank (or Other Monetary Funds – In Transit) and credit AR; unpaid amounts stay in transit. Platform service fees and commissions debit Selling Expense – Platform Service Fee against AR, since deductions offset the receivable. Advertising debits Selling Expense – Promotion against payables or bank, as ads usually run off a separately topped-up account. Refunds are red-letter entries against revenue and VAT with matching red-letter invoices where issued. The exact chart follows the company's accounting policy and advisor confirmation — this is the common e-commerce pattern.
Posting into Kingdee Cosmic
The typical chain is receivable document → receipt document → voucher. Over the WebAPI: write receivables with the Save / BatchSave operations using the appropriate FormId; after Submit and Audit, voucher templates generate the GL entries automatically. Receivable lines join revenue reconciliation at line-level internal code — that line linkage is the key to the three-way loop across platform statements, supply-chain orders and ERP accounting. Deduction-side data can generate other-payable or expense documents, offset and written off against receivables. Yonyou's YonSuite / U8 lines follow the same idea: business documents first, vouchers from templates — never post directly to the GL interface, which bypasses document-level controls and will not survive audit.
Idempotency and Re-run Control
The biggest engineering risk is duplicate generation. Build an idempotency key from platform + store + settlement cycle + document type + reconciliation batch, stored as the source document number in the ERP; on re-runs, query by that number first and skip or update. Submit large volumes in batches via BatchSave, retrying only failed batches. Write back ERP document numbers, approval states and voucher numbers to the reconciliation system — both sides must agree before the loop is closed. And block posting into closed periods at the reconciliation side, before any API call.
Go-Live Checklist
Have the account mapping signed off by the finance lead and version-controlled; run in parallel for one to two months, reconciling API-generated vouchers against manual ones before cutover; and monthly, spot-check the three-way tie: reconciliation totals equal ERP AR activity equals voucher activity. With the last mile connected, the value chain is complete — from platform statement to GL voucher, no manual handling anywhere.