How should an AP team be structured at different invoice volumes?

Small teams run on generalists who do everything, which is efficient until volume makes context-switching costly and depth impossible. Specialization typically emerges as volume and complexity rise: separating processing from exception handling first, then carving out payment operations and vendor-master ownership as those become full jobs. The trigger isn't a headcount number - it's when generalists start dropping quality because no one owns the hard parts. Multi-entity complexity accelerates specialization; a single-entity high-volume shop may stay generalist longer than a low-volume multi-entity one.

Automation removes the data-entry roles and grows the judgment roles. The post-automation AP team is smaller in headcount-per-invoice but more skilled: fewer keyers, more exception analysts, vendor-relationship owners, and people doing the spend analysis the team never had capacity for. The work moves up the value chain - from processing transactions to managing exceptions, controls, and insight. Teams that automate without redefining roles end up with the same people doing less obvious work; teams that succeed redeploy freed capacity to higher-value functions.

AP needs a dedicated manager when its volume, exception load, or team size makes it more than a part of someone's job - typically once there's a team to coordinate, vendor escalations to own, and SLAs to manage. Below that, rolling up under the controller or accounting manager is fine and avoids overhead. The signal is when AP issues start consuming the controller's time at the expense of their actual role.

Centralized maximizes efficiency and consistency but can lose entity-specific knowledge; entity-aligned pods preserve local relationships and rules but duplicate effort; hub-and-spoke (central processing, local approval and exception handling) is the common compromise. The right answer depends on how different the entities really are - similar entities centralize well, genuinely distinct ones (different countries, regimes, vendor bases) argue for more local presence. Process consolidation on a common platform often matters more than the org-chart shape.

Under the controller (most common): AP is treated as accounting, with emphasis on accuracy and close. Under shared services: emphasis on efficiency and SLAs across entities. Under procurement: tighter P2P integration but potential SoD tension. Under treasury: payment-timing and cash focus. Each home shifts AP's priorities toward that function's mandate - pick the reporting line that matches what you most need AP to optimize, and watch the segregation-of-duties implications of the procurement option.

Alphabet splits are legacy and don't scale (they balance load but ignore skill and complexity). Entity-based suits genuinely distinct entities. Invoice-type (PO vs non-PO, by complexity) lets you match work to skill. Queue-based - routing by what the work needs (exceptions here, routine there) - scales best in automated environments because it sends judgment work to judgment people and routine work to a fast path. Modern automated AP increasingly organizes by queue and exception type rather than by who owns which vendors.

At smaller scale AP or procurement owns it as part of their job. As vendor count and fraud/compliance stakes grow, vendor-master maintenance becomes its own function - because it's a control point (banking changes, duplicates, dormant records) that deserves dedicated ownership and segregation from invoice processing. The split-out signal is when master-data errors start causing payment or fraud problems, which means it's too important to be a side task.

Stampli's core promise to AP org design is absorbing growth without proportional headcount - higher throughput per finance employee as volume, entities, and complexity rise, because intelligent automation and configurable workflows let the same team handle more. The structural implication Stampli emphasizes is the shift it enables: as the AI takes the repetitive entry and lookup work, the team's role moves toward validation, exceptions, and the strategic oversight that headcount was previously consumed away from. Scale comes from system design, not from adding keyers.