OCEB 2 Business Intermediate study materials
OCEB 2 Business Intermediate study resources

Accounts Payable Shared Services: Reengineer Before Automating

OCEB 2 Business Intermediate · Put your knowledge to work in context.

All case studies

Accounts Payable Shared Services: Reengineer Before Automating

A shared services center processes accounts payable for five European entities: 280,000 invoices a year. Each entity keeps its own approval matrix, chart of accounts and exception rules. The center has 62 FTEs, a 6.2% duplicate-payment rate found by audit, and an average invoice cycle time of 12 days. Three entities still receive paper invoices; two use e-invoicing. The center manager wants to apply robotic process automation to the current steps and promises a 20% FTE reduction. The group CFO wants a redesign before any automation, with a target of 4 days cycle time and a single control framework. A consultant proposes lift-and-shift standardization: one approval matrix for all entities, one ERP instance, and a central exception desk. Entity controllers resist losing local approval flexibility; the works council requires consultation on role changes.

1. Should the center automate the current process with RPA or reengineer first? Make a recommendation and justify it using the evidence.

Read the worked answer

Reengineer first. The evidence shows structural variation and control weakness, not just manual effort. Five entities have different approval matrices, charts of accounts and exception rules, and the duplicate-payment rate is 6.2%. Applying RPA to the current steps would automate five variants of the same process, lock in unnecessary complexity and make future standardization harder. It would also risk automating the conditions that allow duplicate payments. Process reengineering should eliminate duplicated validation, consolidate entity-specific rules where they do not serve a legal or tax purpose, and create a single control framework before selecting automation. However, reengineering should not be a big-bang removal of all local flexibility. The team should distinguish statutory local requirements, such as VAT and local reporting, from self-imposed local preferences. The target should be a standard core process with controlled local extensions, not one undifferentiated process. RPA can then be applied to the remaining stable, high-volume, rule-based steps, and the 20% FTE reduction should be recalculated after the redesign. The works council consultation and controller resistance are not obstacles to ignore; they are design inputs that determine what can be standardized.

2. Propose a to-be process architecture and control framework for the five entities. What should be standardized, what can remain local, and why?

Read the worked answer

The to-be architecture should define one standard accounts payable process at level two, with a common invoice intake, validation, three-way match, exception handling, payment proposal and reconciliation flow. Standardize the approval matrix by risk and value rather than by entity, the chart-of-accounts mapping, supplier master-data rules, duplicate-payment checks and the exception reason codes. Move to e-invoicing or OCR for all entities, with a central exception desk for unmatched invoices and master-data problems. Apply duplicate checks before payment, not after. Local extensions should be limited to statutory tax, legal and reporting requirements, local language for supplier communication, and entity-specific regulatory approvals where law requires them. These should be documented as controlled variants with a named owner and a review date, not left as informal practice. The control framework should include segregation of duties, a single approval audit trail, supplier master-data change control, duplicate-payment monitoring, and reconciliation between the ERP and the bank. A central process owner should own the standard, while entity controllers own statutory compliance. This separation lets the center standardize without pretending that local law does not exist.

3. The works council and controllers resist. How would you govern the redesign and measure success?

Read the worked answer

Governance should start with a mandate from the CFO and a process owner who has authority across the five entities. A steering group should include the shared services lead, entity controllers, IT, internal audit and works council representatives. The redesign should be phased, beginning with a diagnostic that separates statutory local requirements from local preference, followed by a pilot in one entity. Role changes should be handled through consultation, transparency and reskilling, not announced after the design is fixed. Controllers need a clear statement of what they keep: statutory compliance, local tax and a defined escalation route. Success should be measured with a balanced set: invoice cycle time at median and 90th percentile, duplicate-payment rate, first-time-right rate, exception rate by reason, cost per invoice, e-invoicing adoption, and the number of uncontrolled process variants. A target of 4 days cycle time should be tracked with a quality guardrail, because speed achieved by paying invalid invoices is not success. The 20% FTE reduction should be a consequence of validated demand reduction, not a predetermined target that drives the design. Review the control framework with internal audit before go-live and after the first quarter.