When a group adds subsidiaries, plants or a central purchasing entity, its approval policy is rarely wrong. What changes is how hard it becomes to prove the policy was followed. A multi-level approval architecture built on one principle, centralize the standard and delegate the execution, lets a group keep a single standard of authority while each entity still runs its own requests. This article compares three architecture models, sets out a four-layer framework, and explains how Kyta eRequest and Kyta eFlow on Kyta Platform support it.

Why is approval harder in a multi-entity group than in a single company?

In a single company, the approval question is "who approves?" In a multi-entity group it becomes "under which entity's authority, and against whose threshold?" One payment can originate in one entity, draw on a budget allocated by another, and be contracted through a third.

Picture a request to buy a packaging line at a subsidiary's plant in an industrial park in northern Vietnam. The capital budget is allocated by the parent company in the annual plan. The supplier contract is signed through the group's central purchasing entity. Three entities, three sets of internal rules and three legal representatives sit behind one payment. This is an illustrative scenario with no client named, but its structure will be familiar to most groups with five or more entities.

With one or two entities, these flows stay correct because a few people know the rules and know whom to ask. That works for years. As entities multiply, the combinations of entity, spend category, value threshold and role grow far faster than the number of people who understand the whole policy. The policy is still right on paper, yet answering "under whose authority was this approved?" starts to take days whenever auditors ask.

Internal approval and signing authority are separate layers

Process design often blurs the line between an approval decision and a signature. Approval is an internal judgment: the request is justified, within budget and has passed the required checks. Signing is a legal act. Under Vietnamese enterprise law, contracts are signed by an entity's legal representative or a person that representative has authorized. In a group, the final approver at the parent company may have no authority to sign for a subsidiary.

When both layers are merged into one chain, the hard questions surface at audit time: the signature is valid, but where is the approval behind it, and under which rule? The COSO Internal Control - Integrated Framework (2013) covers control activities in Principle 10, under which management segregates incompatible duties and selects alternative controls where segregation is not practical. For a multi-entity group, separating the approval layer from the signing layer is a direct way to apply that principle.

Three approval architecture models for multi-entity groups

No single model fits every group. The three below are all common, and each suits a particular stage of growth and degree of similarity between entities.

Centralized at the parent company

The centralized model is a better fit for groups with few entities in one industry, where transactions are high in value but low in frequency. Every decision passes through one point, so consistency is high and control is clear. When policy changes, it is updated in one place, and there are few integration points to manage. Processing speed, however, depends on the capacity of the center, and requests tend to pile up at period end. As volume grows, the center itself can become the bottleneck. It remains a sensible choice when leadership wants sight of every large commitment.

Fully delegated to each entity

Full delegation suits groups whose entities operate in different industries or markets with high autonomy, almost as independent companies. Each entity designs approval flows around its own operations, so decisions are fast within its boundaries. The trade-off is consistency, which tends to be low to medium because each entity interprets the rules in its own way. When group policy changes, every entity updates separately and the results then need to be reconciled. The main concern is that cross-entity audit questions become hard to answer.

Hybrid: central standard, local execution

The hybrid model fits groups with many entities that need consolidated reporting and one standard of authority. The standard stays consistent at group level, while thresholds and approvers are configured per entity. Requests within local thresholds are handled quickly where they arise, and requests above the ceiling escalate. When policy changes, the standard is updated once and every entity inherits it. The model balances control and speed, but it needs a person or team that owns the authority matrix and reviews it on a schedule. The rest of this article focuses on the hybrid model.

A four-layer framework for multi-entity approvals

The hybrid model is easier to describe than to run. Implementation experience shows it holds up when designed as four distinct layers, each with its own owner.

Layer 1. Intake: standardize the request at the start

Every request needs the attributes required for routing: originating entity, paying entity, request type, cost center, amount and currency. If one is missing here, every rule downstream has to guess. Most returned requests are not the result of strict approvers. They were incomplete when they were created.

Layer 2. Rules: the authority matrix as data

The delegation of authority (DoA) matrix works better as a data table than as a pre-drawn org chart. Each row combines an entity, a request type, a value threshold and an approver role. The parent sets the group-wide ceiling, and each entity configures its thresholds and approvers below it. When people change jobs, only the role holder is updated and the flow itself stays intact.

Layer 3. Exceptions: delegation, absence and escalation

An approval flow shows its quality in how it handles exceptions. Temporary delegation needs a clear scope and an end date. Overdue requests should escalate against an agreed service level (SLA). Requests sent back for more information should keep their history rather than restart as new requests. When exceptions are handled outside the system by chat or phone, the trail breaks exactly where auditors look first.

Layer 4. Evidence: a decision trail, not only a signature trail

Each step should record who approved, when, on which document version and under which row of the matrix. Those four facts let a team answer an audit question in minutes, and they give the group the data to review the matrix itself.

How do Kyta eRequest and Kyta eFlow support the four layers?

Within Kyta Platform, a business orchestration and automation (BOAT) platform from FPT IS, Kyta eRequest handles request intake and routing, while Kyta eFlow automates rule-based approval workflows. Both connect to the platform's contract, identity and signature modules, depending on the modules deployed.

Kyta eRequest lets a group standardize request forms by type and by entity, so each request carries its routing attributes from the moment it is created. Kyta eFlow configures approval flows through low-code and no-code settings, routes by amount and by request or contract type, supports approval on mobile devices and tracks status in real time. When the authority matrix changes, operations teams adjust rules in configuration rather than opening a new development project.

For requests that lead to a commercial contract, contract risk review results from Kyta Intelligent can be fed into the flow before the request reaches an approver. These results support review and do not replace legal assessment or the decision of the authorized person. Where external parties or signers take part, VNeID-standard identity verification confirms the right person before the request moves on. VNeID is Vietnam's national digital identity app. After approval, the correct legal representative of each entity signs through Kyta Signature electronic signatures, with timestamps and document versions preserved.

The trade-off is that the group needs a person or team that owns the authority matrix and reviews it on a schedule. The platform keeps rules applied consistently, but it does not decide which rules are right. If the group runs an ERP, the integration approach for organization and budget data should be settled early, so the two systems never hold different versions of the same threshold.

What should you measure to know the architecture is working?

Four indicators are usually enough: approval cycle time by entity and by level, the share of requests sent back, the share routed through exceptions or delegation, and the time needed to answer a cross-entity audit question.

Cycle time by level shows which step holds requests without adding control. As an illustration, assume a group handles 2,000 requests a month and each waits an extra 1.5 days on average at a step that only re-confirms an earlier decision. That adds up to roughly 3,000 request-days of waiting each month, before counting the opportunity cost of delayed spend. To turn these indicators into financial terms, CFOs can feed them into a total cost of ownership (TCO) and ROI model for an operations platform, built on a clear baseline and a 90-day pilot.

A high exception rate usually signals that the matrix no longer reflects how the business operates, rather than a lack of discipline among users. Technology makes these indicators measurable, but control still depends on keeping the policy current and reviewing it regularly.

Frequently asked questions

How is multi-level approval different from multi-step approval?

Multi-step approval is a fixed chain of approvers. Multi-level approval ties each level to a specific authority and threshold, so the number of levels changes with amount, request type and entity. A small request may need one level, while a large capital commitment passes through four.

Should a group use one approval flow for every subsidiary?

Usually one standard, not necessarily one flow. The standard covers authority ceilings, mandatory control steps and evidence requirements. Thresholds and approvers are better configured per entity, so they reflect each unit's size and context.

Does Kyta eFlow replace the approval module in an ERP?

Not necessarily. Many companies keep accounting document approvals in the ERP and use a separate orchestration layer for requests, contracts and cross-entity flows. The choice depends on how often the policy changes and on the company's integration approach.

What should be prepared before digitizing multi-entity approvals?

Three things: review and agree the current authority matrix, name an owner for it, and pick one or two flows with the most handoffs for a pilot. Digitizing a matrix that has not been agreed tends to make inconsistency run faster.

To discuss an approval architecture for your group, contact Kyta Platform: kyta.fpt.com | Hotline 1900 636 121 (ext. 2) | support.kyta@fpt.com.