Accounts Payable Shared Services: Centralizing AP Across Business Units
Accounts payable shared services is an operating model where several business units hand their AP work to one internal team that runs a single process on shared systems, with entity-level controls and reporting back to each unit.
The savings case is well documented. Digital World Class finance organizations run at 45% lower cost as a percentage of revenue than their peers, according to The Hackett Group's 2025 Digital World Class Finance research, and consolidating transaction processing is a large part of how they get there.
The design case is where these programs get hard. Once you consolidate, you inherit questions the decentralized model never made you answer. Which entity approves what. Who pays for the center. What a business unit is entitled to expect when an invoice sits in a queue for four days. Companies that treat centralization as a software purchase tend to relocate the work rather than reduce it.
Key Takeaways
A shared services center is an internal team running one AP process for multiple business units, which separates it from outsourcing, where a third party owns the staff and the process.
AP is usually the first function centralized because the work is high volume, rules-driven, and mostly independent of local business knowledge.
The cost case is real, and it comes from process standardization and volume concentration rather than from the org chart change itself.
Entity-level routing, chargebacks, and service levels are the design decisions that determine whether the center holds. Getting them wrong is what pushes business units to rebuild shadow AP.
Shared services rarely means one ERP. The AP layer has to sit across several ledgers and return clean postings to each one.
What is a shared services model in accounting?
A shared services model consolidates a back-office function that several business units used to run separately into one internal organization with a single process, one set of systems, and defined service levels. In accounting, it usually starts with transaction processing rather than judgment work.
AP tends to go first. The work is high volume and rules-driven, and it rarely depends on knowing the local business the way revenue recognition or forecasting does. Centralizing changes who runs each step of the accounts payable process and which systems they run it in. The steps themselves stay the same. The entity that owns the spend still approves it, and the center still has to post to that entity's ledger.
Vocabulary trips people up before the design does, so it's worth pinning down what a center is, what it does all day, and where it stops.
What is the difference between a shared services center and GBS?
A shared services center handles one function, or one region, under a single delivery model. Global business services is the layer above it, where several functions run under one governance structure and one leadership team across regions.
The distinction matters more for accountability than for org charts. An SSC director owns AP throughput for the entities in scope. A GBS leader is accountable for total back-office cost across finance, HR, IT, and procurement together, rather than for one function's unit cost.
The economics favor the broader structure. Approximately 55% of organizations with a global GBS leader role have achieved over 20% average savings, according to Deloitte's 2025 Global Business Services Survey, which collected leader responses from more than 30 countries. That gap is one reason companies that start with a finance-only center often keep expanding scope after the first two years.
What does a shared services AP team do day to day?
The center runs the transactional half of payables end to end and hands back anything that requires a business decision. On a normal Tuesday that means:
Invoice intake across every channel the entities use, including email, supplier portals, and paper
Coding to the right entity, cost center, and GL account
Two-way and three-way matching against purchase orders and receipts
Approval routing under each entity's thresholds and delegation rules
Payment execution across virtual card, ACH, check, and cross-border rails
Supplier inquiries and statement reconciliation
Period-close support, including accruals and open-item reporting
Master data maintenance for suppliers and banking details
What stays with the business unit is judgment, and it's the expensive kind. Did the invoice reflect what was delivered? Is a variance acceptable? Is a supplier relationship worth protecting through a dispute? Centers that try to absorb those calls end up staffed like the decentralized model they replaced.
How is this different from outsourcing AP?
Shared services keeps the work inside the company and moves it to one internal team. Outsourcing hands the work to a third party under a contract with defined scope and pricing. The two get compared constantly, and for good reason, because both concentrate volume and both promise a lower unit cost.
Dimension | Shared services | Outsourced AP |
Who employs the staff | Your company | The provider |
Where process design sits | Internal, with the center | Negotiated in the statement of work |
How cost behaves | Fixed headcount, allocated to units | Per-transaction or per-FTE fees |
Speed of change | An internal decision | A change order |
Institutional knowledge | Retained | Held partly by the provider |
The models coexist more often than not. Plenty of centers outsource a slice of intake or one hard entity while keeping approvals and payment execution in house.
The benefits of outsourcing accounts payable read a lot like the benefits of centralizing it. The difference shows up when something breaks. In a center, you fix it on Monday. Under a business process outsourcing agreement, you file a change request and wait for a quote.
Why do companies centralize accounts payable?
Four reasons carry almost every business case. Unit cost, control consistency, audit readiness, and negotiating position with suppliers.
Cost is what gets the approval signature, and the spread between good and average AP operations is wide enough to fund a program on its own. The top quintile of AP organizations, measured on lowest average processing cost and shortest cycle times, process an invoice for $2.78 against $12.88 for everyone else, according to Ardent Partners' Accounts Payable Metrics that Matter in 2025. Run 200,000 invoices a year through that gap and the difference is roughly $2 million in annual processing cost.
Payment timing is the second-order effect, and it moves more money than most business cases admit. Concentrating volume changes when invoices get approved, which shows up in the accounts payable turnover ratio and in how much early-payment discount capture is genuinely available to the treasury team.
What does centralization do to cost per invoice?
It lowers cost per invoice through two mechanisms, and the reorganization itself is neither of them.
The first is volume concentration. A clerk who codes invoices for one entity absorbs interruptions, context switches, and idle time that a queue-fed center removes by pooling work. The second is process standardization. When eleven entities each keep their own coding conventions and approval habits, no automation investment pays back, because every rule carries eleven exceptions.
Standardization is the harder of the two and the one that gets skipped. Plenty of centers consolidate headcount into a single building, keep every entity's legacy process intact, and then wonder why unit cost barely moved. The org chart changed. The work didn't.
What does it do to control and audit readiness?
Centralizing gives you one control design instead of eleven, which is the largest audit benefit of the model. Segregation of duties gets defined once. Approval thresholds get set once. The audit trail lives in one system with one time source.
That's worth more than it sounds during an accounts payable audit. Sampling across a decentralized AP function means reconstructing eleven different approval conventions from eleven different systems, and half the evidence arrives as screenshots. Sampling across a center means pulling one report.
The trap is assuming centralization creates the control by itself. It creates the opportunity for one control design. Someone still has to write that design, and someone still has to get the entity controllers to accept it.
Where does fraud exposure change?
Concentration cuts both ways. A single payment function is a larger target and a stronger control point, and which one wins depends almost entirely on how the center handles supplier master data.
The exposure is well mapped. 74% of organizations were affected by business email compromise in 2025, according to AFP's 2026 Payments Fraud and Control Survey Report, based on a January 2026 survey of 465 treasury practitioners. Reported BEC losses reached $3,046,598,558 in 2025, per the FBI Internet Crime Complaint Center's 2025 IC3 Annual Report.
A center helps when it owns supplier banking changes as a controlled process with callback verification and dual approval. A center hurts when it becomes a high-volume queue where a plausible bank-change email gets processed by whoever picks it up next. Most accounts payable fraud losses at centralized shops trace back to master data rather than payment execution.
See how Corpay handles entity-level AP routing inside a shared services center. Schedule a demo with our team.
Protect cash flow with modern AP
Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.
Download the whitepaper
How do you design AP for multiple business units?
Design comes down to five decisions, and the centers I've watched struggle got at least one of them wrong before go-live.
Entity-level queues, so work is separated before anyone touches it
Routing rules per entity, covering approvers, thresholds, and delegation
Chargeback and cost allocation, meaning how the center gets funded
Service levels the business units agree to, with escalation paths
Exception ownership, meaning who resolves a mismatch and who decides when it stalls
Chargebacks deserve more attention than they get. A center funded from corporate overhead has no natural discipline on volume, and the business units have no reason to clean up their intake habits. A center that charges per invoice, or per entity by transaction share, creates that pressure immediately, and it also creates arguments about the rate. Both funding models work. The one that fails is the center funded by whoever complains least.
Exception ownership is the other quiet failure. When a three-way match breaks, someone has to decide whether the receipt was wrong, the PO was wrong, or the invoice was wrong. Centers that route every exception back to the business unit turn into a mailbox with headcount. Centers that resolve everything internally start guessing about deliveries they never saw. The workable line is usually that the center owns data exceptions and the unit owns commercial ones.
Payment execution shapes the design too. Consolidating AP consolidates the payment run, which is where the money and the fraud exposure sit. U.S. noncash payments totaled 236.6 billion in 2024, with ACH representing almost three quarters of noncash payments by value, according to the Federal Reserve's initial findings from the 2025 triennial Federal Reserve Payments Study. Most of what a center pays moves on that rail, so entity-level remittance detail matters more than the headline payment-method mix.
How do you route invoices when each entity has its own approvers?
You give each entity its own queue, its own approver matrix, and its own thresholds, then you resist every request to make an exception for a single supplier.
The people living it state the requirement plainly. One finance team described what it needed as "proper subsidiary segregation, including subsidiary-specific AP queues or inboxes, entity-level approval workflows, routing rules per subsidiary." That's the whole design in one sentence, and it's the reason a single shared inbox stops working around the third entity.
Where it breaks is payment method. A VP of accounting posting in r/Netsuite described running "different approval routing for different payment methods" and finding that "they can interfere with each other." Two routing dimensions, entity and payment type, multiply instead of adding, and the matrix gets unmanageable fast.
Backup approvers are the unglamorous part that decides whether the model survives a vacation week. Every threshold needs a named alternate, and the delegation has to be time-boxed and logged. Designing an invoice approval workflow for one entity is straightforward. Designing eleven that share a queue without leaking approval authority across legal entities is the real job, and it's the same problem NetSuite multi-subsidiary AP automation has to solve inside a single ERP.
How do you handle multiple ERPs across entities?
You put the capture and approval layer above the ERPs and let each ledger keep its own postings. Shared services groups formed through acquisition almost never share one ERP, and forcing a migration before the center works is how these programs lose two years.
The practical requirement is that the AP layer reads entity structure from each system and writes back in that system's format. Corpay's AP automation connects through 180+ ERP integrations via API, SFTP, or file-based connections. Published connectors cover the five most common mid-market ledgers. NetSuite, Sage Intacct, Microsoft Dynamics 365, Acumatica, and QuickBooks each have a supported path.
If a consolidation onto one ERP is genuinely coming, sequence it after the center stabilizes. An AP automation ERP migration is hard enough without renegotiating approval authority with eleven controllers in the same quarter. Where the entities in scope run systems you inherited rather than chose, start by mapping what an ERP does for each of them before promising anyone a single process.
How do you set service levels the business units will accept?
You publish targets the units can verify, and you report against them whether or not you hit them.
Service levels fail when they're written from the center's point of view. A three-day turnaround target measured from the day the center receives a clean, coded invoice means nothing to a plant manager whose supplier is calling about an invoice that's four weeks old. Measure from the date the invoice arrived anywhere in the company.
Commitment | Typical target | Measured from |
Invoice acknowledged | 1 business day | Arrival at any intake channel |
Clean invoice approved and scheduled | 3 to 5 business days | Arrival, not center receipt |
Exception first response | 2 business days | Exception created |
Supplier inquiry response | 1 business day | Inquiry received |
Entity reporting pack delivered | 3 business days after close | Period close date |
Targets vary with entity mix and volume. What matters is that the clock starts where the business unit thinks it starts.
Escalation matters as much as the target itself. Every service level needs a named person at the center, a named person at the unit, and a rule for what happens on day six. Without that, one missed payment turns into a business unit quietly rebuilding its own AP function, which is the failure mode that ends these programs.
What does good look like for a shared services AP function?
Good is measurable, and it looks like top-quartile cycle time, a stable exception rate, and a supplier base that stopped calling.
The cycle-time benchmark is the clearest one to aim at. The top-performing fifth of AP organizations process an invoice in 3.1 days against 17.4 days for everyone else, according to the same Ardent Partners metrics report. A center that gets every entity to five days is doing well. A center still sitting at fifteen days two years in has a process problem the org change didn't fix. The staffing benchmark points the same direction, since Digital World Class finance organizations require 42% fewer full-time equivalents across key finance functions than their peers, per The Hackett Group's 2025 research.
Two criteria decide the platform choice for this buyer, and they're worth naming. The first is scale, meaning one system that spans entities and ERPs and enrolls suppliers through an existing payment network instead of one-off outreach per entity. The second is security and compliance, which is the model's whole premise. A function built to standardize control has to prove the control, which means segregation of duties enforced across entity boundaries, an audit trail that survives a subsidiary line, and third-party attestation of the platform itself. Corpay is SOC 2 Type II compliant, and for a shared services center that attestation belongs in the audit evidence package rather than in a sales deck.
Reconciliation is the other test, and it's the one that decides whether the center shortens close or lengthens it. Getting payment reconciliation right per entity, without a manual journal to fix the posting afterward, is the difference. Clean intake and disciplined master data are most of what managing accounts payable effectively comes down to at any size. In a center, those habits have to hold across every ledger in scope at the same time, which is harder than it sounds when one entity's controller is on leave.
Which metrics should a shared services center report?
Report the same five every month, per entity and in total, and resist the urge to add more.
Cost per invoice, calculated as total center operating cost divided by invoices processed
Cycle time from invoice arrival to payment scheduled, reported at the median and the 90th percentile
First-time match rate, meaning the share of invoices that clear matching with no human touch
Exception rate and aging, split by whether the center or the business unit owns the exception
Supplier inquiry volume per thousand invoices, the best early warning that something upstream broke
The 90th percentile matters more than the median, and most centers report only the median. A center with a three-day median and a thirty-day tail has an angry-supplier problem that the average hides completely. Ask for the tail before you sign off on anyone's dashboard.
How do you keep supplier experience from degrading after centralization?
Give suppliers one place to look and one place to ask, then staff the asking part properly.
Centralization usually improves payment reliability and degrades payment communication, at least in the first year. The supplier used to call someone at the plant who knew the invoice. Now they call a queue. Review data on AP platforms puts "lack of payment visibility" near the top of the buyer pain list, with practitioners asking specifically for "real-time payment tracking," and finance leaders naming month-end close delays and compliance burden in the same breath.
Three things fix most of it:
A supplier portal where remittance and status are self-service rather than a phone call
Enrollment support that handles banking details and payment-method changes as a managed process
A named escalation contact per entity, so a supplier with a real problem skips the general queue
Centers that also take on payment vendor consolidation get a second benefit here, because a supplier receiving one remittance format across five of your entities has far less to reconcile on its own side.
What does automation change, and what does it not?
Automation raises throughput and consistency. It doesn't decide who approves what, how the center gets funded, or what the business units are owed.
Finance is where the spending is going. Approximately 58% of respondents have already begun or are planning to begin their GenAI journey, with finance and IT the top functions for implementation, including invoice management, according to Deloitte's 2025 Global Business Services Survey.
The order of operations is what people get wrong. Automating a process that eleven entities each run differently encodes eleven variants into software, and now the variants are expensive to change. Standardize the routing rules and coding conventions first, then automate. Evaluating AP automation software before the operating model is settled tends to produce a tool that fits nobody.
Automation genuinely removes touch count. Capture, coding, matching, and payment execution stop consuming clerk hours, which is where the unit-cost gap between top and average performers comes from. Exception handling and supplier relationships stay, and those scale with judgment rather than with software.
Run centralized AP across entities with Corpay
A shared services center needs one capture and approval layer that spans entities and ledgers, one payment run that covers every rail, and reconciliation that lands in the right entity's books without a manual journal. That's the shape of Corpay's Procure-to-Pay solution set.
Corpay's AP automation captures invoices from every intake channel your entities use, codes them to the right entity and account, and routes them through each unit's approval matrix. Payment then goes out in a single run by virtual card, ACH, check, or cross-border transfer. Our managed service handles supplier enrollment and payment follow-up, which is the work a center is usually asked to absorb without added headcount. Reconciliation returns to each entity's ledger through published ERP integrations, so the center doesn't turn into a journal-entry factory.
Over 800,000 customers trust Corpay. For a shared services group, the part that counts is that the same controls, approval logic, and audit trail apply to every entity in scope, which is what the operating model promised and what decentralized AP could never deliver.
Frequently Asked Questions
What is a shared service in accounting?
A shared service in accounting is a back-office function that several business units use in common, delivered by one internal team on one process. Transactional work like accounts payable, accounts receivable, and payroll moves to the center. Policy and judgment stay with the entities.
What is an example of a shared service?
Accounts payable is the most common example. One AP team receives invoices for every legal entity, codes and matches them, routes approvals under each entity's rules, and executes one payment run. Payroll, travel and expense processing, and vendor master data are the usual next candidates.
What is the difference between a shared services center and GBS?
A shared services center delivers one function, often for one region, under a single delivery model and one set of service levels. Global business services is the governance layer above several centers. It covers finance, HR, IT, and procurement under one leadership team. GBS is simply the broader remit, and it owns total back-office cost rather than one function's unit economics.
What are the duties of a shared services AP team?
The center owns invoice intake and coding, matching, approval routing, and payment execution. It also handles supplier inquiries, master data maintenance, and period-close reporting. The business unit keeps decisions about whether goods were received and whether a variance is acceptable.
Is shared services the same as outsourcing accounts payable?
No. Shared services keeps AP inside the company under one internal team. Outsourcing transfers the work to a third-party provider under contract. Companies often run both, using a provider for intake or a single entity while keeping approvals and payment execution in the center.
What are the benefits and challenges of a finance shared service center?
The benefits are lower cost per transaction, consistent controls, cleaner audit evidence, and better cross-entity data. The challenges are entity resistance, service levels that feel worse to the units at first, chargeback disputes, and the risk that centralizing relocates work instead of reducing it.
How long does it take to stand up an AP shared services center?
It depends on entity count, ERP diversity, and how much process standardization happens before the move. Most programs run in waves, starting with one or two entities on a shared ERP, then adding entities once the routing rules and service levels hold under load.
Do all entities need to be on the same ERP?
No. A center can run across several ledgers if the AP layer sits above them, reading each entity's structure and writing postings back in that system's format. Forcing an ERP consolidation before the center is stable usually delays both projects.
Switch to Corpay
Discover how making the move to Corpay streamlines payments and strengthens your business.
Talk to an ExpertSmarter payments. Stronger growth. Keep business moving.
Corpay powers payments for 800,000+ businesses worldwide. Let’s build what’s next for yours.