Principal Procure-to-Pay Architecture Director — ERP Exception State Design

The mandate

A software group's ERP programme lacks a consistent design for payable exceptions. The same invoice can appear as blocked, awaiting receipt or disputed in different views, with each status implying a different owner and permitted action. Starting on 26 October 2026, the principal procure-to-pay architecture director will produce an exception-state architecture and implementation-ready decision specification over four months. The remit addresses status meaning and transitions, not supplier-integrity policy, automation-tool selection or the operation of live payment queues. The design must remove ambiguity before configuration fixes inconsistent assumptions into the new system.

The first artifact, due 11 December 2026, is a traced exception baseline covering selected entity and invoice pathways, including evidence of conflicting status use. The second, due 22 January 2027, is a state catalogue, ownership model and permitted-transition specification with worked cases. The final artifact, due 26 February 2027, is a replay-tested design pack and transfer record for process and ERP teams. A transition must describe the event, required evidence, authorised actor and resulting status; renaming a queue without resolving those decisions will not meet the design requirement.

The global procure-to-pay executive and ERP finance workstream lead accept each stage, with entity controllers reviewing control consequences. Baseline counts must reconcile to the agreed extract and every selected exception must trace to its source event. Design tests include partial receipt, disputed credit, cancelled approval and a reopened invoice after incorrect closure. Final acceptance requires internal analysts to replay unseen combinations using the specification and reach the agreed state and owner without consultant interpretation. Payment is 25%, 35% and 40% across accepted stages, not dependent on later ERP go-live or realised productivity savings.

The sponsor provides extracts, process logs, existing control positions, local exception rules and fourteen available contributors. Three days weekly are reserved for Chennai-led analysis and design workshops. Configuring production systems, changing accounting policy and clearing the current backlog are excluded. New entities, interfaces or exception families require a written change decision with fee and schedule implications. Technology retains implementation and security authority; finance owners approve professional treatments. The project ends with a design that those teams can implement and maintain, not a promise to solve every upstream purchasing defect exposed during the diagnostic.

What you will own

• Map exception-state usage from actual event logs and owner interviews, distinguishing system labels from the business condition they are meant to represent before consolidating apparently similar queues.
• Construct the diagnostic population with extract controls and source references, identifying contradictory statuses and owner gaps without claiming that every blocked invoice reflects a technology defect.
• Design the state catalogue around explicit entry, exit and evidence conditions, preserving justified local differences and prohibiting transitions that erase a dispute before its authorised resolution.
• Specify actor permissions and escalation routes for each transition, separating operational correction, receipt confirmation and controller judgement so one convenient user role cannot silently acquire incompatible authorities.
• Build worked replay cases for partial receipt, credit dispute and reopened obligations, showing how simultaneous conditions affect status precedence and which owner remains accountable for the next decision.
• Validate the architecture with process and ERP leads against agreed control positions, documenting unresolved policy questions separately instead of embedding a consultant's preferred accounting answer into configuration requirements.
• Transfer the accepted specification through unseen-case replay by internal analysts, leaving a change procedure that can incorporate future exception families without recreating contradictory meanings across entity implementations.

Candidate qualifications

• Demonstrate payable or ERP process design through a specific ambiguity you resolved between status, owner and permissible action. Explain the underlying events, why the existing labels were insufficient and how you tested the replacement logic. The required evidence is a maintainable decision specification, not only a process diagram or a catalogue of system defects passed to technology colleagues.
• Bring 22–28 years of finance operations, shared services or transformation experience, with software, technology or financial-services complexity. You should have owned substantive process-standardisation decisions and understand where local requirements must remain distinct. A named ERP certification is not mandatory; applied knowledge of records, permissions and downstream settlement consequences must be strong enough to challenge proposed configuration with informed finance judgement.
• Evidence rigorous exception testing that includes combinations and reversals, not just a successful linear invoice path. Describe how you treated partial receipt, a disputed amount or an incorrectly closed item without losing audit evidence. You must recognise when a design question requires an authorised controller or policy decision and retain that uncertainty rather than making a convenient assumption to complete the specification.
• Show bounded consulting delivery with agreed inputs, review owners and reproducible acceptance. Reserve three days weekly for four months and explain how you transferred a design that internal teams could use without your narration. Strong facilitation across operational and technology specialists is essential, particularly when a proposed standard changes existing queue ownership or reveals that apparently efficient local workarounds weaken control.

Application

Applications for this mandate are received in one way only: through the India Board Terminal's application process. It is automated end to end. Your Executive Passport travels to the mandate holder in its confidential form, your answers to the three questions below are read before anything else in your file, and every stage that follows is recorded on your applications page.

There is no address to write to and no intermediary to call. The mandate holder reads what the Terminal delivers and nothing else, which is what keeps the process the same for every applicant and keeps your name out of it until you release it. Applications close on 10 October 2026. Mandate reference CVU-CON-2026-IND-131.