Centralize invoices in multi-entity groups: AP

The problem: 4 subsidiaries, 4 inboxes, no unified control

A group with four entities (holding, two operating subsidiaries and a real-estate company) receives supplier invoices through four different channels: each subsidiary's accounting email, supplier portal, postal mail and FACe for those working with public administration. The usual outcome:

Cross-entity duplicates: the same supplier issues an invoice to the holding and to an operating subsidiary for the same service.
Lost approvals because the manager of one subsidiary has no access to another's inbox.
Input VAT reports that have to be consolidated manually at quarter-end.
Volume rebate negotiations that are not exploited because each subsidiary negotiates separately.

The solution is not to merge the books (each entity has its own tax ID, its own tax obligations and its own balance sheet) but to centralize the accounts payable process while preserving each entity's identity.

What "multi-tenant" means in AP

In a multi-tenant AP system, each group entity is a tenant: it has its own data space, its own supplier master, its own approval rules and its own tax configuration (VAT, withholding, special regime). Tenants share the platform and the automation engine, but the data is never crossed.

Dimension	Centralized without multi-tenant	Centralized with multi-tenant
Supplier master	One shared catalogue	Global catalogue + per-entity profile (terms, bank account, specific rebate)
Approval rules	Single for the whole group	Per entity and per amount (each subsidiary has its matrix)
Booking	One chart of accounts	Chart of accounts per entity (PGCE or sector variant)
VAT / withholding	Single treatment	Tax regime per entity (general, simplified, OSS, exempt)
Reporting	Consolidated only	Per entity + consolidated with intercompany elimination
Access	All users see everything	RBAC: a user can have different roles in each tenant

Architecture of centralized AP: five layers

Layer 1: Unified ingestion

All invoices enter through a single receipt point (group inbox, supplier portal, API, FACe) with automatic routing to the correct entity. The router identifies the target entity by the receiver's tax ID on the invoice or by the destination email address.

Layer 2: Extraction and validation per entity

The extraction engine (OCR + LLM) captures invoice fields. Validation applies tenant rules: is the supplier in this entity's master? Does the receiver's tax ID match this entity? Is the VAT rate valid for this subsidiary's tax regime?

Layer 3: Three-way matching per PO

Each subsidiary has its own POs. The three-way matching engine compares invoice against PO and delivery note within the tenant's space: it never matches an invoice from operating company A against a PO from operating company B. The variance logic is identical for all entities, but it executes in isolated context.

Layer 4: Approval workflow per entity

Each entity configures its own approval matrix:

<EUR 1,000: automatic approval if the supplier is regular and the invoice matches the PO.
EUR 1,000-10,000: area manager approval for that subsidiary.
>EUR 10,000: group CFO approval (role with cross-entity approval-only access).

The same user can be an approver across all subsidiaries but with differentiated roles: they only see the invoices they are authorised to approve in each entity.

Layer 5: Segregated payment and booking

Payment is issued from the corresponding entity's bank account, not from a centralized treasury without attribution. Booking happens on each entity's general ledger entry, with the correct tax ID as the taxable subject.

Automated accounts payable for groups

ininvoice supports multiple entities in a single workspace. Each subsidiary keeps its tax ID, supplier master and approval workflow. The group CFO consolidates in real time.

Request a group demo →

Single supplier vs per-entity supplier: managing the master

The most frequent dilemma in groups is whether to keep a global supplier catalogue or one per subsidiary. The practical answer: global catalogue for supplier identity (tax ID, legal name, verified bank account, risk scoring) and per-entity profile for commercial terms (negotiated price, rebate, payment term, accounting category).

Field	Global level (group)	Entity level (subsidiary)
Tax ID / VAT	Yes: single identity	Not duplicated
Legal name	Yes	Local alias if it differs
Verified IBAN	Yes: unique per supplier	Documented exceptions
Anti-fraud risk score	Yes: computed at group level	Inherited, local adjustment possible
Rebate / volume discount	Group-wide accumulation for negotiation	Applied per entity per local contract
Payment terms (days)	Group standard	Override per local contract
Accounting category	Suggestion	Final 4XX account per subsidiary

This model lets the group negotiate rebates on total accumulated volume (summing purchases from all subsidiaries to the same supplier) while each entity books and pays independently.

Intercompany invoices: the special case

When a group entity invoices another (shared services, staff secondments, premises use), the invoice must follow the same AP cycle as any external invoice, with two differences:

Elimination on consolidation. The issuer's revenue and the receiver's expense are eliminated in the group's consolidated balance sheet. If AP does not flag these invoices as intercompany, the consolidation process is manual and error-prone.
Transfer pricing. The invoice must reflect market price under related-party rules (art. 18 LIS). The AP engine can automatically flag these invoices for documentary review.

This information is general guidance. Consult your tax adviser about the treatment of related-party transactions and the documentation required by the AEAT.

Four common errors in multi-entity AP

1. A single receipt inbox with no automatic routing

If all invoices arrive at invoices@group.com with no automatic routing, someone has to classify them manually. With 4 subsidiaries and 300 invoices/month, that is between 5 and 10 hours a week of sorting.

2. Users with full access to all entities

If the purchasing manager of operating company A can see and approve invoices from operating company B, responsibility is diluted and an internal-fraud avenue opens up. RBAC per tenant is a basic control.

3. Not tagging intercompany invoices

Without tagging, consolidation requires manually finding which invoices are between group entities. In groups with 10 or more entities, this can take days at quarter close.

4. Rebates that are never claimed because nobody consolidates them

Each subsidiary negotiates separately. The supplier accumulates volume by client tax ID, not by group. Without group-level purchase consolidation, rebate thresholds are not reached and the discount is lost. A group AP system must aggregate purchases to each supplier by summing all entities.

Real case: food distribution group, 3 subsidiaries, 380 invoices/month

A family-owned food distribution group with holding and two regional operating subsidiaries managed its accounts payable with three independent installations of accounting software. Monthly close required manual consolidation in Excel: 12 hours of the CFO's work each month.

After centralizing AP on a multi-tenant platform:

Monthly close time dropped from 12 hours to 2.5 hours (direct export to each subsidiary's accounting ERP).
3 common suppliers were identified where the group exceeded quarterly rebate thresholds: additional saving of EUR 8,400 in the first year.
Intercompany invoices (14 per month between holding and operating subsidiaries) are tagged automatically and excluded from external spend reporting.

Does your group manage more than 2 entities?

ininvoice lets you add entities at no extra per-entity cost. The CFO has consolidated view; each subsidiary operates autonomously. Operational in 48 h.

See multi-entity demo →

How to measure whether your multi-entity AP works

Three operational metrics that signal centralization is working:

Correct automatic routing rate. Percentage of invoices the system assigns to the correct entity with no manual intervention. Target: >97%. Below 90% indicates a problem in the router config or in the tax-ID master.
Per-entity approval cycle. Days from receipt to approval, broken down by subsidiary. If one subsidiary consistently takes twice as long as the others, its approval workflow has a bottleneck.
Rebates claimed vs potential. Rebate actually invoiced by suppliers vs the rebate the group was entitled to under negotiated terms. The difference is money left on the table.

Integration with touchless accounts payable

Multi-entity centralization and touchless automation are complementary, not alternatives. Centralization solves the organisational problem (who processes what). Touchless automation solves the operational problem (how it is processed without manual work). A group that centralizes without automating simply concentrates the manual work in one place; a group that automates without centralizing has 4 siloed automations that do not talk to each other.

Recommended sequence: first centralize ingestion and the supplier master, then activate touchless automation entity by entity, starting with the highest-volume one.

FAQ on multi-entity AP

Can the same person be an approver in multiple subsidiaries?: Yes. The user has a global profile on the platform but with different roles in each tenant. They can be an unlimited approver in the holding and an up-to-EUR 5,000 approver in an operating company. Each approval is logged with the entity and the active role at that moment.
How is VAT handled when the holding provides services to subsidiaries?: The intercompany invoice must include VAT if the transaction is subject (art. 4 LIVA). The receiver books it as deductible input VAT in its return. On consolidation, both entries are eliminated but each entity's VAT remains in its individual return. Consult your tax adviser.
Does the supplier payment term in Law 15/2010 apply per subsidiary or per group?: The 30-day term (60 for non-SME companies) applies per contract and per debtor, i.e. per each entity signing the contract. The group cannot offset one subsidiary's delay with another's advance payment. This information is general guidance. Consult your tax adviser.
What if the supplier issues the invoice to the holding's tax ID but the PO is from an operating subsidiary?: It is a supplier error: the tax invoice must be issued to the real buyer's tax ID. The AP engine flags this invoice as an entity error and puts it in review. An invoice issued to the holding cannot be booked in the operating subsidiary without a corrective invoice from the supplier.
How does SII affect groups with multiple subsidiaries?: Each entity required to use SII (annual revenue >EUR 6M or voluntary) transmits its records independently to the AEAT. There is no consolidated group SII. A multi-tenant AP system that generates the SII XML per entity greatly simplifies this obligation. Consult your tax adviser to confirm the SII threshold applicable to your group.
Is it possible to centralize payments from a single group treasury?: Operationally yes, but it requires the paying entity (normally the holding) to have a formal power of representation or a cash pooling contract. From a tax perspective, the payment must be documented as a charge to the intercompany current account. Without that documentation, it may be interpreted as a non-deductible gratuity. Consult your tax and legal adviser.

Conclusion

Centralizing accounts payable across a multi-entity group does not mean losing tax control or each subsidiary's operational autonomy. It means processing invoices once, against the correct entity, through a shared flow that respects each entity's rules. The result: faster close, claimed rebates, and a CFO who sees the entire group without opening four different tabs.

If your group manages more than 100 invoices/month across all its entities, the cost of not centralizing (in hours, in errors and in unclaimed discounts) far exceeds the cost of the platform.

Centralize invoices in multi-entity groups: consolidated AP without losing entity identity