Organizations that grow through acquisition typically inherit AP processes from each acquired entity. The acquired company has its own ERP configuration, its own vendor master, its own approval policies, its own payment practices, and often its own AP team with established habits.
Over time, the group operates multiple distinct AP processes that share a name but little else. Each entity codes expenses differently, uses different approval thresholds, maintains separate vendor master records for the same suppliers, and reports AP metrics on different bases. The finance team at the group level cannot produce a consolidated AP view because the underlying data is incompatible.
Standardizing AP processes across entities is not primarily a technology project. It is a policy, data, and change management project that technology supports. Organizations that treat it as a platform rollout consistently encounter the same problems as organizations that never attempted standardization, because they addressed the symptoms rather than the causes.
What Standardization Actually Means
Standardization does not mean identical. It means consistent on the dimensions that drive control quality and data comparability while allowing variation on the dimensions that reflect legitimate local differences.
What should be standardized
- Vendor master management: a single canonical vendor record per supplier across all entities, with consistent naming, tax ID, and payment details
- Approval thresholds: a consistent policy for the invoice value levels that require each tier of approval, applied uniformly across entities unless local regulatory requirements differ
- GL account structure: a standard chart of accounts that maps to local statutory requirements through a translation layer rather than requiring separate charts per entity
- Invoice coding policy: consistent rules for how common expense categories are coded across entities, enabling consolidated cost reporting
- Payment terms policy: a consistent approach to standard payment terms for defined vendor categories, managed at the group level
What can legitimately vary by entity
- Local language processing: invoices in the entity's local language handled by local AP staff
- Local tax treatment: VAT, GST, and withholding tax requirements that are jurisdiction specific
- Local e invoicing compliance: entities in mandate countries comply with local requirements without requiring the entire group to adopt that format
- Local banking relationships: entities use local banking infrastructure for operational payments while group treasury coordinates cross entity cash management
- Local supplier relationships: procurement and AP relationships with suppliers who serve only that entity
The Standardization Sequence
Step 1: Vendor master consolidation
The vendor master is where standardization delivers the most immediate value and the most direct fraud risk reduction. A consolidated vendor master means:
- The same supplier appears once, under a consistent name, with a single verified payment account, regardless of which entity purchases from them
- Changes to supplier banking details trigger a verification workflow that covers all entities simultaneously
- Spend analysis across the group shows total spend with each supplier rather than fragmented views from each entity's separate records
- Duplicate vendor entries that enable duplicate payment are eliminated at the data level
Vendor master consolidation is technically straightforward with modern AP platforms but organizationally complex. Entities with established supplier relationships resist changes to their vendor records. Local AP teams have existing workflows built around their local vendor master. The change management required to move to a consolidated vendor master is often more significant than the technical implementation.
Step 2: Chart of accounts alignment
A common chart of accounts is not always achievable immediately, particularly when acquired entities are on different ERPs with different account structures. A practical intermediate approach: a mapping layer that translates each entity's local account codes to a standard group reporting hierarchy. Entities continue to code to their local chart. Consolidation maps local codes to group codes automatically.
This approach produces consistent group level reporting without requiring every entity to recode historical transactions or rebuild their local financial reporting. The mapping layer is an investment, but it is smaller than the disruption of forcing immediate chart of accounts changes on acquired entities during integration.
Step 3: Approval policy alignment
Define a group approval policy that specifies the minimum approval requirements for each invoice value tier. Entities may add additional approval requirements above the group minimum based on local governance needs, but they cannot apply approval standards below the group minimum.
This approach prevents the approval threshold fragmentation that occurs when each entity sets its own policy independently. It maintains local governance flexibility while establishing a control floor that applies group wide.
Step 4: Payment terms standardization
Payment terms negotiated locally by entity procurement teams with the same supplier create inconsistency that affects DPO calculation, cash flow forecasting accuracy, and early payment program effectiveness. Where the same supplier serves multiple entities, group procurement should negotiate consistent terms that apply across entities, unless volume or relationship differences justify differentiated terms.
Step 5: Reporting metric standardization
AP metrics reported by each entity need a consistent definition to be comparable. Cost per invoice, invoice cycle time, touchless rate, and exception rate should be calculated using the same methodology across entities. A touchless rate calculated to include only PO backed invoices in one entity and all invoices in another is not comparable and produces misleading group level metrics.
The Role of Technology in Standardization
Technology enables standardization but does not create it. The policy decisions about what to standardize, the organizational alignment on those policies, and the change management required to shift established local practices are all human work that precedes the technology implementation.
The technology role is to enforce the standardized policies consistently across entities without requiring manual coordination. A platform that allows each entity to configure its own vendor master rules will not produce a consolidated vendor master regardless of how good the consolidation features are. The platform configuration must reflect the policy decisions already made.
Managing Resistance
Standardization creates organizational friction. Local AP teams resist changes to processes they have built and understand. Entity level finance directors may see group standardization as a loss of local autonomy. Acquired company staff may have loyalty to practices from the prior organization.
The most effective approach is to distinguish between policies that are non negotiable at the group level because they affect control quality or data integrity, and policies where local variation is genuinely acceptable. Being specific about which is which reduces resistance by making clear that standardization has limits rather than being a full override of local practice.
It also helps to communicate the value from the entity's perspective rather than from the group finance perspective. Entity level AP teams benefit from vendor master consolidation because it reduces duplicate vendors and simplifies supplier management. They benefit from consistent approval policies because they produce clearer escalation paths. Framing standardization as a service to local operations rather than a control from above changes the conversation.
