How difficult is it to manage ten branches with one account? Kailing Technology's expense control system uses multi-organization switching to achieve data isolation and independent permissions in parallel

A chain retail enterprise set up a new regional subsidiary in Southwest China. In the week its business license was issued, site selection, recruitment, and store renovation were already underway, while finance received only one sentence: "Reimbursements start next month, please arrange the system." Arrange what? Creating accounts is only a surface action; what really needs to be determined is this new entity's position in the group expense control system: which layer its accounts belong to, whose account pays the money, who reviews the documents, and who can see the data. When Kailing Technology implements Lingdong Reimbursement for group clients, this kind of "new entity onboarding" scenario occurs more frequently than full-scale go-live—full go-live is one-time, while onboarding is the norm.

Whether onboarding is done cleanly directly determines the workload of the shared service center afterward. If done sloppily, it means a pile of manual reconciliation and after-the-fact account splitting; if done clearly, employees of the new company can submit reimbursements normally the next day, and the shared service center simply has one more company in the list it can process. Below, following the real order in implementation, we break down the configuration actions required to onboard a new legal entity.

▍Onboarding a new entity: Kailing Technology breaks the configuration work into five steps

Lingdong Reimbursement supports multiple organizations, multiple roles, and multiple processes. These three 'multiples' translate into five configuration steps during implementation: create organizations, define standards, configure processes, bind accounts, and define scope. These five steps are not equivalent—some can be copied wholesale from a sister company with a similar business model, changing only the differences, while others must be set up individually per legal entity due to legal person responsibilities. Kailing Technology marks these two categories separately in the implementation checklist to avoid copying things that should not be copied.

▍Building the organization: which layer a new node hangs on determines everything downstream

The organization tree is the foundation of the entire configuration. Whether a new entity is directly attached under the group or under a regional business unit determines not only how the hierarchy is displayed—it also determines to which level the company's data is consolidated upward, whether the regional head can see it, and who the next level is when approvals move upward.

What is most prone to rework during implementation is the department granularity. A retail enterprise's regional subsidiary may have more than a dozen stores under it. Whether stores are built as organizational nodes or only as expense dimensions depends on whether independent approval and independent data viewing by store are needed. Once this layer is thought through, standards, processes, and permissions can all be attached accordingly; if thought wrong, when the stores expand to thirty and the organizational tree has to be dismantled retroactively, the cost will be more than just changing a few configurations.

After the node is created and personnel are assigned, when authorized colleagues of this new entity log in, it will appear in the organization list at the top; for those not authorized, this company will not appear in their list.

▍Setting standards: what can be copied wholesale and what cannot

Reimbursement limits are one of the more contentious items when a new entity is onboarded. The group has a unified framework, but local prices, travel radius, and store schedules are not consistent, and the same intra-city transportation limit may not be suitable for different regions. Smart Reimbursement allows each entity to carry its own set of standards, and when employees fill out forms, the system uses the set for the entity they are currently in and will not cross into another entity's set.

The conventional approach is to first find a sister company with a similar business form and copy the entire setup, then go through differences item by item: whether accommodation tiers should be adjusted by city, whether meal allowances change with store shifts, and whether there are locally unique expense categories. Copying saves the time of sorting out the system from scratch, while going through differences item by item saves the time of repeatedly patching after launch. If this step is done solidly, employees will be prompted before submission when exceeding standards, rather than being returned only at the approval stage.

▍Configure flows and bind accounts: one governs signatures, the other governs disbursement

Approval chains are configured separately by entity. Some subsidiaries have simple business, where the department head signs and it goes directly to finance; others require headquarters review again due to investment relationships. Reimbursement form fields and approval nodes can be adjusted by dragging and dropping in the designer. Adding a level, removing a level, and whether rejection returns to the initiator or the previous level are all completed in configuration, and changes for one entity do not affect other entities. Approval messages can be pushed to the office tools employees use daily, and can be handled by clicking the link. This part requires almost no additional configuration when new entities are onboarded.

The payment line must be handled separately and cannot reuse another company's ready-made configuration. The new entity's invoicing information and bank account are bound to the legal representative. Whether direct bank-enterprise connection is enabled and which bank to use must be filled in according to this company's own situation. After the reimbursement form is approved, payment is made from this entity's account, and after the bank receipt is returned, it is also linked to this entity's documents. Cutting corners here by borrowing a sister company's account is equivalent to mixing the capital flows of two companies together, and later reconciliation, voucher preparation, and archiving will all have to be repaid with interest.

The confirmers for these two lines are often not the same group: the approval hierarchy follows the business perspective and usually requires the new company's responsible person to approve; account and direct connection information follows the finance perspective and can only be filled in after the corporate account is opened and online banking permissions are in place. When scheduling implementation, pushing both tasks in parallel saves more time than waiting sequentially—set up the approval flow according to the template first, and after the account information is completed, run a small payment to verify whether the link works.

▍Define scope: who can see, who cannot see, and who can roll up

The first four steps define "how to do it"; this step defines "who can do it and what they can see." Data isolation and independent permissions point to two different things: the former governs visibility scope—the new entity's invoice pool, documents, and ledgers will not appear in sibling companies' interfaces; the latter governs operational scope—the same person may be a preparer at this new company but an approver at the original regional company. Roles follow the organization and do not carry over just because someone has approval rights at one company.

What needs to be confirmed person by person during access is precisely the authorization scope: regional finance usually needs to enter several entities simultaneously, store managers only have permissions on their own store node, and headquarters roles obtain cross-organization summary viewing scope. Authorization is granted layer by layer along the organization tree, and who can receive data at which layer is determined at this step.

The matter of standards is also closed out at this step: after the new entity's expense categories are aligned with the group standards, the headquarters can include it when viewing group expenses and budget execution, without waiting for this company to separately report a table at month-end. How reports retrieve data and how to drill down is another topic; at the onboarding stage, it is only necessary to confirm that this entity's dimensions have been attached.

▍FAQ

Q: When the group establishes a new subsidiary, what stages must it go through to integrate the expense control and reimbursement system?

A: The usual sequence is five steps: create organizational nodes, set reimbursement limits, configure approval processes, bind the entity's accounts, and define personnel authorization and data visibility scope. The first three steps can mostly be copied from a sibling entity with a similar business form and then adjusted for differences; accounts and authorization involve legal entity responsibility and individual permissions, so they need to be set entity by entity and confirmed person by person.

Q: Each company has different reimbursement limits; do we need to build a separate system for each?

A: No need. Within the same system, each entity can maintain its own standards and approval flows in parallel without overwriting each other. Whichever entity an employee enters, the system performs verification and prompts according to that entity's rules; group-unified parts are embedded in templates, and regional differences are adjusted item by item after copying.

Q: If the organization tree is set up incorrectly, can it still be changed?

A: It can be adjusted, but the later it is done, the greater the cost. Node positions affect data aggregation paths, approval superiors, and viewing scope. It is recommended to set the granularity during the access stage according to the store or branch scale for the next two to three years, avoiding large-scale splitting after scale increases.

Q: When personnel transfer within the group, how should permissions change accordingly?

A: Permissions follow the organization and role, not fixed to the person. During transfer, adjust the person's belonging node on the organization tree and role, and the accessible organization scope changes accordingly; historical documents of the original entity remain with the original entity and do not transfer with the person.

Q: After a new entity is onboarded, can headquarters still view it together with other companies?

A: Yes. The headquarters role obtains a cross-organization summary viewing scope. Once the dimensions of a new entity are attached during access, it is included in the group standard. Each entity remains isolated from the others and cannot see each other's documents and invoices horizontally.

The group wants to add new entities to the expense control and reimbursement system. Welcome to talk with Kailing Technology about your organizational structure and configuration needs: https://www.kailingteck.com/feikong/ .

As a comprehensive business-finance-tax digitalization solution service provider, Kailing Technology provides business-finance-tax management digital transformation products and operational services for various government agencies, institutions, and large, medium, and small enterprises. The product line includes:

Solutions for businesses including sales contract management system, procurement contract management system, fully digitalized Leqi interface project, output automatic invoicing system, reverse invoicing system, invoice issuance for individuals system, employee expense control and reimbursement system, input VAT invoice management system, supply chain collaborative reconciliation system, image OCR recognition system, automatic financial bookkeeping system, and electronic accounting archives system, comprehensively driving the digitalization process across various fields.

If you have any business-finance-tax digital transformation needs, welcome to contact us. Beijing Kailing Technology will serve you wholeheartedly.

Keywords: Kailing Technology, Lingdong Reimbursement, expense control reimbursement system, multi-entity switching, group expense control, new entity onboarding, data isolation, independent permissions, financial shared service center