Centralizing Accounts Payable: Shared Services for Multi-Entity Contractors
Construction companies rarely stay a single legal entity for long. A general contractor opens a separate company for its self-perform concrete work. It spins up a special-purpose entity for a large joint venture. It acquires a mechanical contractor two states away and keeps the brand. It adds a service division, a development arm, an equipment-holding company. Each move makes business sense on its own. But there is a quiet side effect that almost nobody plans for: every new entity tends to grow its own accounts payable process, its own vendor list, its own coding habits, and often its own software.
A few years in, the parent company looks down and finds it does not have one AP function — it has five or eight or twelve, each doing the same work a different way. The same supplier exists as four vendor records across four entities, with four sets of payment terms. One division pays in twelve days; another lets invoices age past sixty. Controls range from solid to nonexistent depending on which entity you look at, and the consolidated close becomes a scramble of reconciling intercompany activity that should have been clean. This is the decentralized-AP problem, and for a growing contractor it is one of the most expensive operational drags there is. The fix is a shared-services model — and this guide covers the trade-offs, what to centralize versus keep local, the operating model, the role of technology, and a phased path to get there.
Decentralized AP is not wrong by default — when a contractor is small, having AP sit close to the work is reasonable and fast. The problem is that decentralization is rarely a decision. Nobody chooses to run AP eight different ways; it just happens, one entity at a time, and the costs stay invisible until they are large.
What decentralized AP costs a multi-entity contractor
- Duplicated effort — every entity carries its own AP staff doing identical keying, matching, and filing, with no economies of scale
- A fragmented vendor master — the same subcontractor or supplier exists multiple times across entities, defeating duplicate detection and spend analysis
- Lost negotiating leverage — the company never sees its true total spend with a vendor, so it negotiates as several small buyers, not one large one
- Inconsistent controls — segregation of duties, approval limits, and new-vendor verification are strong in some entities and absent in others
- Uneven payment behavior — discounts captured in one division are missed in another; some entities pay late and strain subs, others pay early and strain cash
- A painful consolidation close — intercompany transactions, mismatched coding, and incompatible systems make the close slow and error-prone
- No enterprise visibility — leadership cannot answer basic questions about total payables or cash needs without manually stitching reports together
The fraud exposure deserves its own mention. Fragmented AP is a gift to anyone committing payment fraud: a shell vendor set up in one weakly controlled entity is never cross-checked against the others, a bank-detail change that a disciplined division would catch sails through a lax one, and insiders learn which entity has the loosest controls and route activity there.
~0%
Share of organizations that have experienced attempted or actual payments fraud in a typical year — exposure that uneven, entity-by-entity controls magnify (AFP)
Before reorganizing anything, be honest about what each model buys you — this is a trade-off, not a slam dunk. A centralized AP function delivers scale, consistency, and visibility. One team processing the payables of every entity develops deep expertise and runs at a much lower cost per invoice than several small teams. Controls are designed once and applied everywhere. The vendor master is unified, so the company can see and negotiate its full spend. Leadership gets a single, trustworthy view of payables and cash, and the consolidated close gets dramatically easier because everyone codes and processes the same way.
Decentralized AP keeps processing close to the work. Local staff know the jobs, the project managers, and the local subcontractor base, and can chase down a coding question or a missing approval by walking across the office. For a truly independent acquisition still on its own systems, or an entity in a different region with a distinct line of business, that closeness has genuine value and forced centralization can do real damage.
The strongest model for most multi-entity contractors is not pure centralization — it is a hub-and-spoke shared-services model. Transactional processing and controls centralize for scale and consistency; judgment that depends on jobsite knowledge stays with the people who have it. The skill is drawing that line correctly.
The single most important design decision in a shared-services AP model is the boundary: which activities move to the central team and which stay with the entities and the field. Set it too far toward centralization and you create a remote bottleneck that does not understand the work; set it too far the other way and you have rebuilt the fragmented mess with a new org chart. The reliable principle: centralize the transactional and the standard-setting, and keep local the judgment that requires job knowledge.
Functions that belong in the shared-services center
- The vendor master — one governed vendor database for all entities, with central new-vendor setup, verification, and bank-detail change control
- Coding standards — a common chart of accounts and cost-code structure, so a charge is coded the same way regardless of which entity incurs it
- Invoice capture and processing — a single intake channel, extraction, matching, and entry operation serving every entity
- Internal controls — uniform approval thresholds, segregation of duties, and duplicate and fraud screening applied consistently everywhere
- Payment execution — a consolidated, controlled payment run with dual authorization, rather than each entity cutting its own checks
- Compliance documentation — central tracking of W-9s, certificates of insurance, lien waivers, and 1099 preparation across all entities
- Reporting and analytics — enterprise payables, cash forecasting, and vendor-spend reporting from one consolidated dataset
Decisions that should stay with the entities and the field
- Invoice approval — the project manager or superintendent who can confirm the work was performed and the quantities are right stays the approver
- Cost-code assignment for job-specific work — the field knows which activity a charge belongs to; central coding governs the structure, not every line
- Pay-application and change-order review — verifying percent complete against jobsite reality is inherently a field judgment
- Local vendor and subcontractor relationships — relationship management and performance assessment stay with the operating teams
- Budget ownership — project managers and division leaders still own their numbers; centralizing processing does not transfer accountability
The clearest way to hold the line: the center owns how an invoice is processed, controlled, and paid; the field owns whether the underlying spend is legitimate. Central AP should never approve that a subcontractor's pay application reflects real progress — but it should own the unified vendor record, enforce the duplicate check, and execute the payment once the right field person has approved.
Get AP insights in your inbox
A short monthly roundup of construction AP + accounting posts. No spam, ever.
No spam. Unsubscribe anytime.
A shared-services center is more than a relocated AP team — it is an internal service provider with defined customers, service levels, and accountability for delivering them. Setting it up that way is what keeps the entities from experiencing centralization as a loss of control and responsiveness.
Elements of a working AP shared-services model
- A clear charter — what the center does, what the entities still do, and where the boundary sits, written down and agreed
- Service-level agreements — committed turnaround times for processing, exception resolution, and vendor inquiries
- Standardized, documented procedures — one playbook for intake, coding, matching, approval routing, and payment, followed by everyone
- An escalation and exception path — a defined, fast route for invoices that do not fit the standard process so they do not stall
- Performance metrics — cost per invoice, cycle time, touchless rate, discount capture, and error rate, reported and reviewed
- A governance forum — a regular check-in between the center and entity finance leaders to surface friction and adjust
Two of these deserve emphasis. The most common reason entities resist centralization is the fear that a remote team will be slower than the clerk down the hall — so explicit, measured SLAs, and hitting them, are how the center earns trust. The exception path matters just as much: the center runs efficiently because most invoices follow a standard route, but construction generates a steady stream of non-standard invoices, and if those clog the queue, the whole model gets a bad reputation fast. A deliberate fast lane for exceptions protects both throughput and credibility.
“Our worry going in was that the divisions would feel like they lost control of their own bills. What changed their minds was the SLA — they could see exactly when an invoice would be processed, and the central team hit those dates more reliably than the old setup ever did.”
— Controller, multi-entity construction group
Centralizing AP is fundamentally an operating-model change, but technology is what makes the model practical at scale — you cannot run efficient shared services on paper, email threads, and a different accounting system in every entity. The capabilities that matter most are multi-entity support, a single intake channel, and a governed vendor master.
Multi-entity support means one platform that handles every legal entity while keeping their books properly separate — correct entity attribution, clean intercompany handling, and no logging into eight systems. A single intake channel gives every entity's invoices one front door, where they can be extracted, deduplicated, and routed automatically. And the governed vendor master ensures a supplier exists once across the enterprise, with verification and bank-detail changes controlled centrally. Covinly is built for this multi-entity reality: a centralized vendor master and consistent capture, matching, and control logic across entities, with approval routing that still directs each invoice to the right project manager in the right division — central processing, local approval, one system.
If the centralization business case depends on a tool, evaluate it specifically for multi-entity operation — a unified vendor master, per-entity reporting and clean consolidation, and routing flexible enough to send approvals to the correct field approver in each division. A single-entity AP tool deployed many times does not deliver shared services.
Centralization fails most often when it is attempted as a single overnight switch — every entity, every process, the same day — which maximizes disruption and risk. The reliable approach is phased: prove the model on a narrow scope, then extend it entity by entity.
A workable sequence for centralizing AP
- Phase 1 — Assess and design. Map how each entity does AP today, quantify the cost of fragmentation, and design the target model: the central-versus-local boundary, the standard chart of accounts and cost codes, the controls, and the SLAs.
- Phase 2 — Clean the vendor master. Deduplicate and standardize vendor records across entities and reverify high-risk vendors — the clean, unified vendor master is the foundation everything else sits on.
- Phase 3 — Standardize the process and platform. Document the common procedures and put the entities on shared multi-entity technology with a single intake channel.
- Phase 4 — Pilot with one or two entities. Move a small set — ideally one straightforward entity and one moderately complex one — into the center, run it against the SLAs, and fix what breaks.
- Phase 5 — Roll out entity by entity. Onboard the remaining entities in waves, carrying lessons from the pilot forward and stabilizing each wave before starting the next.
- Phase 6 — Optimize. With every entity centralized, push the metrics — raise the touchless rate, tighten cycle time, capture more early-pay discounts, tune controls.
Two phases are non-negotiable. Skipping the vendor-master cleanup means centralizing the fragmentation instead of fixing it. And skipping the pilot means betting the whole enterprise on an untested design — a pilot is where you discover the routing gap or the over-aggressive SLA while the blast radius is still one entity, not all of them.
For a multi-entity contractor, decentralized accounts payable is a tax that compounds with every entity added — duplicated cost, fragmented vendor data, uneven controls, lost leverage, and a painful monthly close. Centralizing into a shared-services model addresses all of it at once: scale brings the cost per invoice down, one governed vendor master restores visibility and negotiating power, uniform controls close the fraud gaps, and a single dataset makes enterprise reporting straightforward.
The model that works is not blunt centralization but shared services with a carefully drawn line: centralize the transactional processing, the vendor master, the controls, and the payments, while keeping with the field the approval and coding judgment that depends on knowing the job. Stand the center up as a real internal service provider with SLAs and a fast exception path, put it on multi-entity technology, and get there in phases — clean the vendor master, pilot small, then roll out entity by entity. Done that way, a contractor turns a dozen incompatible AP processes into one disciplined function, without ever taking job knowledge away from the people who have it.
Written by
Sarah Blake
Head of Product
Former AP Manager at a $200M construction firm, now leads product at Covinly. Writes about what AP teams actually need from automation — beyond the marketing promises.
View all posts