Procure-to-Pay (P2P) often looks simple on the surface.
The purchase is completed.
Goods or services are received.
The invoice is received.
The invoice is booked in the ERP.
The vendor is paid.
Simple?
Not really.
In a Global Capability Center (GCC), Global Business Services (GBS), Shared Services Center (SSC), or BPO environment, P2P can be one of the most complex finance operations.
P2P sits at the intersection of Procurement, Finance, Tax, ERP, Treasury, Banking, Vendors, Controls, Compliance and Technology.
Therefore, building a high-performing P2P function requires much more than hiring people to process invoices.
It requires the right organization structure, process design, technology, controls, exception management and continuous improvement framework.
Based on my experience of working with finance operations and transformation, here is how I would approach setting up a P2P function in a GCC/GBS/SSC environment.
1. Start With the Right Organization Structure
One of the first things I would recommend is having two distinct leadership pillars within P2P:
P2P Operations Head
The Operations Head is responsible for running the day-to-day business.
Key responsibilities include:
- Invoice processing
- Exception management
- Payment processing
- SLA management
- Productivity
- Quality
- Operational governance
- Stakeholder management
- Team performance
Business Excellence Head
The Business Excellence Head has a different responsibility.
The focus should be on continuously asking:
How can we make the P2P process better, faster, cheaper and more automated?
Key responsibilities include:
- Process improvement
- Automation
- Productivity enhancement
- Process transformation
- Standardization
- Analytics
- Technology adoption
- Root-cause analysis
- Continuous improvement
This distinction is important.
The Operations Head is focused on running today’s business.
The Business Excellence Head is focused on building tomorrow’s P2P function.
2. Suggested P2P Organization Structure
A typical structure could look like:
CEO>COO / Operations Head>P2P Tower Head>Team Leads>P2P Processors / P2P Analysts
Alongside the operations structure:
Business Excellence Head>Process Excellence / Automation / Transformation Team
The exact reporting structure may vary depending on the size and maturity of the organization.
For a large GCC supporting multiple businesses and geographies, Team Leads can be aligned to:
- Geography
- Business vertical
- Process
- Entity
- Customer/business unit
For example, if a GCC supports ten different business verticals, dedicated Team Leads could be responsible for individual business areas such as telecom, transportation, logistics, retail, manufacturing or other sectors.
The principle is simple:
Clear ownership creates accountability.
3. Processor and P2P Analyst Should Have Different Roles
A common mistake is to expect every P2P employee to perform every activity.
I prefer a clear distinction between transaction processing and exception management.
P2P Processor
The Processor handles standardized and repetitive activities.
For example:
- Invoice validation
- Three-way matching
- PO/GR/Invoice verification
- Checking supporting documents
- ERP invoice posting
- Routine mismatch resolution
- Standard corrections
The objective is:
Speed + Accuracy + Standardization
P2P Analyst
The Analyst handles exceptions and complex cases.
Examples include:
- PO not available
- Goods receipt mismatch
- Budget issues
- Tax issues
- TDS-related issues
- Vendor master problems
- Complex invoice discrepancies
- Business approval issues
- Unusual accounting requirements
The P2P Analyst should therefore be a specialist in exception management.
4. Think of P2P Like a Factory
This is one of the most important concepts in designing a scalable P2P operation.
P2P should operate like a factory.
Imagine starting the day with 1,000 invoices pending for processing.
The objective should not be to manually distribute 1,000 invoices among employees.
Instead, create a standardized production line.
The process could look like:
Invoice Received >Invoice Management System>OCR / Data Capture>PO + GR + Invoice Matching>Auto Posting>Minor Exception >Processor>Complex Exception >P2P Analyst>
Invoice Posted
Payment Proposal
Funding & Business Approval
Payment Processing
Bank
Vendor
This is the P2P factory model.
5. Three-Way Matching Should Be at the Center
The foundation of invoice processing should be:
Purchase Order + Goods Receipt/Service Receipt + Invoice
If these three match within predefined tolerances, the system should ideally allow automatic posting.
In the Indian environment, relevant tax validations can also form part of the control framework.
The philosophy should be:
Don’t make people perform a task that technology can perform reliably.
If the system can validate the PO, GR, invoice and relevant parameters, why should a person manually review the same information?
The objective should be to maximize touchless processing and auto-posting.
6. Exceptions Should Go to Specialists
Suppose 1,000 invoices enter the system.
Imagine:
- 700 invoices match perfectly.
- 200 invoices require minor intervention.
- 100 invoices are complex exceptions.
The ideal model would be:
700
Auto-post
200
Processor intervention
100
P2P Analyst / Specialist
This is much more efficient than having every employee deal with every type of invoice.
The specialist team focuses on where human judgment is actually required.
7. Payment Processing Needs a Separate Control Structure
Once invoices are booked, payment becomes the next major activity.
There should be clear segregation of duties between invoice booking and payment processing.
For example, suppose the organization processes payments twice a week:
Tuesday and Thursday.
On Monday, the payment processing team can:
- Review outstanding invoices.
- Identify invoices due for payment.
- Complete pending clearing/knock-off activities.
- Prepare the payment proposal.
- Validate the payment population.
- Obtain funding confirmation from Treasury.
- Obtain required approval from Business Finance.
On the payment day, the approved payment batch can then be processed.
This creates an appropriate control framework while maintaining operational efficiency.
8. Treasury and Business Finance Are Important Stakeholders
Payment processing is not simply a P2P activity.
It involves coordination between:
P2P > Business Finance > Treasury > Bank
P2P identifies the invoices to be paid.
Treasury confirms funding availability.
Business Finance provides the required business approval.
P2P processes the approved payment according to the organization’s authorization matrix.
This provides appropriate segregation of duties and control.
9. Host-to-Host Banking Can Further Automate the Process
A mature P2P function should look beyond manual bank portal processing.
A host-to-host integration can connect the ERP/payment system directly with the bank.
The flow can look like:
SAP / ERP
Payment Integration
Bank
Payment Processing
Vendor
Depending on the organization’s control framework, payments may require authorization in the bank portal or may follow an approved straight-through processing model.
The objective is to reduce manual intervention while maintaining appropriate controls.
10. Don’t Forget Reverse MIS
The P2P process does not end when the payment instruction leaves SAP.
The next question is:
Did the bank actually process the payment?
Bank statements, such as MT940 or equivalent formats, can provide the required transaction information.
A unique reference such as:
- UTR
- Payment document number
- Transaction reference
- Date
can be used to connect the ERP payment with the bank transaction.
This enables automated clearing and reconciliation.
A mature process can therefore create a reverse MIS mechanism where bank confirmation flows back into the ERP and relevant accounting or reconciliation entries are updated.
This creates a true end-to-end P2P cycle.
11. Vendor Master Is an Important Upstream Control
P2P performance is heavily dependent on vendor master data.
Issues such as:
- Incorrect bank details
- Duplicate vendors
- Incorrect tax information
- Incorrect payment terms
- Incomplete master data
can create significant downstream problems.
Therefore, vendor master governance should be treated as an important upstream component of P2P.
12. Vendor Helpdesk Should Be Technology Enabled
Another important component is the vendor helpdesk.
Vendors should not have to repeatedly call the P2P team asking:
“When will my invoice be paid?”
A mature P2P organization can provide:
- Vendor portal
- Vendor app
- IVR
- Automated email notifications
- Invoice status tracking
- Payment status tracking
Ideally, a vendor should be able to enter an invoice number and see:
Invoice Received ? Under Validation ? Approved ? Posted ? Payment Proposed ? Paid
This can significantly reduce repetitive queries and improve vendor experience.
13. Business Excellence Is Where the Transformation Happens
Now comes the role of the Business Excellence team.
Their fundamental question should be:
What is stopping us from achieving straight-through processing?
Suppose 1,000 invoices are processed every day and 300 require manual intervention.
The wrong question is:
“How can we process those 300 invoices faster?”
The better question is:
“Why are those 300 invoices failing the automated process?”
The Business Excellence team should perform root-cause analysis.
For example:
| Exception | Possible Root Cause | Potential Solution |
|---|---|---|
| No PO | Business process | Mandatory PO policy |
| GR mismatch | Receiving process | Improve GR discipline |
| Tax mismatch | Master/process issue | Automated tax validation |
| Wrong vendor | Master data | Vendor master controls |
| Price mismatch | Procurement process | PO tolerance rules |
| Duplicate invoice | Manual processing | Duplicate detection |
This is how P2P moves from transaction processing to process transformation.
14. Business Excellence Should Own the P2P Rule Book
Every recurring exception should trigger another question:
Can we change the process, system or rule so that this exception does not happen again?
For example:
If invoices repeatedly fail because of a tolerance issue, can the ERP tolerance rule be improved?
If invoices repeatedly arrive without POs, can the procurement process be redesigned?
If vendors repeatedly submit incorrect invoices, can the vendor portal enforce mandatory fields?
If tax errors are frequent, can validation happen earlier?
The objective is not merely to solve exceptions.
It is to eliminate the root cause of exceptions.
15. Technology Stack for a Modern P2P Function
A mature GCC/GBS/SSC P2P function should consider an integrated technology ecosystem.
1. Invoice Management System
Central platform for receiving and processing invoices.
2. OCR / Intelligent Data Capture
Automatically extracts invoice information.
3. Duplicate Invoice Detection
Identifies potential duplicate invoices before payment.
4. Three-Way Matching
Automates PO, GR and invoice matching.
5. Workflow
Routes exceptions and approvals to the appropriate stakeholders.
6. Vendor Portal
Provides vendors with self-service visibility.
7. IVR / Helpdesk
Provides automated invoice and payment status information.
8. ERP Integration
Connects the P2P process with SAP or another ERP.
9. Bank Integration
Supports host-to-host payment processing and reconciliation.
10. Analytics and Dashboard
Provides visibility into:
- Invoice volumes
- Processing time
- Exception rates
- First-time-right %
- Auto-posting %
- Productivity
- Payment performance
- Vendor queries
- Aging
- SLA adherence
16. Measure P2P Like a Factory
A P2P Tower Head should not manage the operation only through invoice volumes.
A mature dashboard should include:
Productivity
- Invoices processed per FTE
- Cost per invoice
- Transactions per processor
Quality
- First-time-right %
- Error rate
- Rework %
Automation
- Auto-posting %
- Touchless processing %
- OCR accuracy
- Straight-through processing %
Timeliness
- Invoice processing SLA
- Exception aging
- Payment SLA
Vendor Experience
- Vendor query volume
- First-contact resolution
- Average response time
- Portal adoption
Financial Impact
- Duplicate payments prevented
- Early-payment discounts
- Late-payment charges avoided
- Working capital improvement
These KPIs help convert P2P from a back-office processing function into a measurable business operation.
17. The Golden Rule: Don’t Automate a Broken Process
There is one principle I strongly recommend:
Don’t automate a broken process.
First:
Standardize
Then:
Simplify
Then:
Control
Then:
Automate
And finally:
Continuously Improve
If you automate a poor process, you may simply create a faster poor process.
18. What Does the Ideal P2P Organization Look Like?
In my view, a mature P2P function should operate around five pillars:
1. People
Right organization structure, skills and accountability.
2. Process
Standardized, documented and controlled processes.
3. Technology
ERP, invoice management, OCR, automation and banking integration.
4. Governance
SLA, controls, segregation of duties, compliance and risk management.
5. Business Excellence
Continuous improvement, transformation, productivity and automation.
The first four make the operation stable.
The fifth makes it better every day.
Final Thoughts
P2P may appear simple from the outside.
Receive invoice.
Book invoice.
Pay vendor.
But in a GCC, GBS, SSC or BPO environment handling thousands of transactions across multiple businesses and geographies, P2P is a sophisticated operating model.
The objective should not simply be:
“How do we process more invoices?”
The better question is:
“How do we build a P2P factory where the maximum number of invoices flow through automatically, while people focus on exceptions, controls and value creation?”
That requires the right organization structure, technology, process discipline and continuous improvement mindset.
This is why I believe a P2P organization should have two strong pillars:
Operations
Run today’s business.
Business Excellence
Build tomorrow’s P2P function.
When these two work together, P2P can move from a transaction-processing department to a high-performing, technology-enabled finance operation that delivers productivity, control, better vendor experience and measurable business value.
Key Takeaway
A mature P2P function should not be designed around people processing invoices. It should be designed around technology processing standard transactions, while people focus on exceptions, controls and continuous improvement.
What is your experience with P2P transformation in a GCC, GBS or Shared Services environment? What has worked—and what hasn’t?
I’d be interested to hear your perspective.
