Reimbursement system integration with Yonyou NC: voucher interface and multi-ledger processing
The core difficulty of NC integration is Mapping of multiple ledgers and multiple organizations: which legal entity a reimbursement belongs to, which account it enters, and whether vouchers for multiple account books need to be generated at the same time. When group enterprises implement expense control, this must be clarified during the research stage, as it determines the data structure of the entire voucher module.
First confirm the relationship between the organization and the ledger
During research, three answers must be obtained: how many legal entities the company has, which ledger each entity corresponds to, and whether one reimbursement needs to generate vouchers for multiple ledgers at the same time.
The third question is the most critical. In most cases, one reimbursement goes into only one set of books, but there are two exceptions:First, cross-legal-entity allocation(headquarters expenses allocated to subsidiaries),Second, it is also necessary to produce both management accounts and statutory accounts. In these two cases, one reimbursement form must generate multiple vouchers, and the data structure must support one-to-many.
Who generates the voucher number
This is a small issue, but if it is not clarified, rework will occur. There are two approaches:
| Method | Pros | Note |
|---|---|---|
| Automatically numbered by NC | Number continuity is guaranteed by the general ledger, with no duplicate numbers | The expense control side must receive and write back the voucher number returned by NC. |
| Generated by the expense control system | Has a number before pushing, facilitating association | It is required to ensure consistency with NC numbering rules and avoid conflict with manual vouchers |
Recommend the first option.Continuity of voucher numbers is the responsibility of the general ledger, if the expense control system manages this, duplicate numbers are likely to occur during concurrency or supplementary entry.
The organizational dimension must run through to the journal entry line
NC voucher entries usually need to carry organization information. The expense control side must ensure that the department and cost center on the reimbursement order can be traced back to the legal entity to which they belong, and correctly populate them when generating entries.
If the expense control organizational structure comes from the OA or HR system, while NC's organizational structure follows financial definitions, the two are often not completely consistent—for example, OA has virtual departments and project teams, while NC does not.This situation requires an organization mapping table, mapping business organizations to financial organizations.
Common errors and troubleshooting sequence
| Error phenomenon | Reason | Processing |
|---|---|---|
| Account does not exist or has been deactivated | The general ledger deactivated an account, but the expense control rules were not synchronized | Periodically sync account master data; deactivated accounts are marked invalid in rules |
| Accounting period closed | The target period has been closed | Verify accounting period status before generation, intercept at the draft stage |
| Missing required auxiliary accounting dimensions | Account requires a project/cost center, but the document did not provide one | Account master data configures required_dims, validated before generation |
| Non-leaf accounts are not allowed for bookkeeping | The rule points to a parent account | Account master data is marked is_leaf, and configuration is restricted to selecting only leaf-level accounts |
| Debit-Credit Imbalance | Incorrect algorithm for amount excluding tax | Tax amount is taken from the invoice value; tax-exclusive amount is derived by subtraction |
The recommended troubleshooting order is: first check the accounting period, then the account, and finally the dimension. Accounting period issues are the most common and easiest to judge; dimension issues are the most hidden—the same account may require different dimensions under different ledgers.
Handling after push failure
NC interfaces may time out and may also return business errors. A complete state machine and failure reason records are required, along with support for manual retry. Retries must be idempotent, with a unique index built on reimbursement order number plus business type.
A practical suggestion:Translate failure reasons into language finance can understand Then display it. The error messages returned by NC are often technical descriptions. If they are thrown directly to finance, they can neither understand nor handle them, and in the end it comes back to IT.
How is this scenario handled in Kailing Technology's expense control system?
Supports multi-legal-entity and multi-ledger mapping, where a single reimbursement form can generate vouchers for multiple ledgers according to allocation rules. Mapping conversion is supported between business organizations and financial organizations, with entry lines automatically carrying organization dimensions. Voucher numbers are generated by the general ledger and written back, while the expense control side retains the source document number for traceability. Push failure reasons are translated into readable prompts, supporting financial self-service correction and retry.
Learn about the Kailing Technology expense control and reimbursement system →
Common Questions
Yes, both scenarios are needed: cross-legal-entity allocation and parallel statutory and management ledgers. The data structure must support one document corresponding to multiple vouchers.
It is recommended that NC assign the number automatically; ensuring number continuity is the responsibility of the general ledger. The expense control side only needs to receive and write back the returned voucher number.
Establish a mapping table from business organizations to financial organizations. Virtual departments and project teams in OA usually have no corresponding entity in NC.
Check in the order of accounting period, account, and dimension. Accounting period is the most common and easiest to judge; dimension issues are the most hidden, and the same account may have different requirements under different ledgers.