ERP go-live marks the start of an AP operational reset, not the end of an implementation project. Exception rates commonly spike in the first 30–90 days as master data gaps, workflow mismatches, and compliance gaps emerge together. Finance controllers who treat go-live as a finish line are the ones rebuilding AP processes 18 months later.
AP practitioners who have been through ERP transitions consistently name the first month after go-live as the most critical. Not because the system fails, but because the organisation is not structured to absorb what the system reveals.
ERP go-live is not an AP milestone. It is an operational reset. The processes that worked in the legacy environment, sometimes because of workarounds invisible to anyone who had not run them for years, no longer apply. New workflows produce outputs that finance teams cannot immediately reconcile. Vendors continue submitting invoices at the same rate. Compliance deadlines do not pause. The team trained on the system during implementation is now running it under live transaction pressure for the first time.
This is not a technology problem. It is a transition management problem that most AP teams are not given the tools to handle.
What Changes in AP the Moment the System Goes Live
The first and most consistent pattern is that exception volumes increase before they decrease. This surprises finance controllers who expected the ERP to reduce manual intervention. The increase is structural, not a sign of implementation failure.
Master data carried forward from the legacy system contains errors that were never visible when transactions flowed through familiar processes. Vendor bank details that were manually verified and re-entered each payment cycle are now static records. GST registration numbers that were checked informally are now being validated against a system that flags discrepancies automatically. PAN details that were assumed correct are now producing TDS mismatches in live transactions.
None of these errors are new. The ERP makes them visible for the first time.
Process ownership also becomes ambiguous in ways that are difficult to anticipate. IT owns the system configuration. Finance owns the payment outcomes. When the system produces an output that finance cannot reconcile, the question of who resolves it, and within what timeframe, is often unanswered. AP teams escalate to IT, IT escalates back, vendors follow up with AP, and the exception queue grows.
The most common reason AP backlogs form in the weeks after go-live is not volume. It is the absence of a defined escalation path for a category of problems that did not exist in the legacy environment.
For a detailed view of how exception categories map to their sources, see AP Exceptions Taxonomy: Classifying by Source and Risk.
The India Compliance Window That Nobody Plans For
The regulatory calendar does not accommodate ERP transitions.
As typically interpreted, GST compliance obligations begin from the month in which the GSTIN becomes active, regardless of where the business is in its ERP transition. For monthly filers, GSTR-1 (outward supplies) is generally due by the 11th of the following month, and GSTR-3B (summary return covering ITC claims and tax payments) by the 20th. Businesses under the QRMP scheme may file quarterly, but the go-live month can still require an IFF submission by the 13th. TDS deducted during the go-live month must, as a general rule, be deposited by the 7th of the following month. Failure to meet this deadline attracts interest at 1.5% per month under Section 201(1A) and potential late fees under Section 234E. These are interpretive positions based on standard compliance guidance and should be verified with your tax advisor for your specific registration date and filing category.
AP teams in their first live month on a new ERP must meet these filing deadlines using clean, reconciled data. The new system has not yet produced this reliably.
Vendor pressure compounds this. From a vendor's perspective, an ERP transition is invisible. Payment terms do not extend because the buyer is in stabilisation. Vendors who supplied on 30-day terms before go-live expect the same after. When payment delays occur because AP cannot process invoices at the previous rate, the vendor relationship deteriorates before the team has stabilised enough to address the root cause.
This is the same pattern that appears when AP automation is introduced and then regresses, as documented in Why AP Automation Doesn't Sustain Invoice Cycle Time Gains. The go-live creates a temporary performance dip that becomes permanent if the stabilisation period is not actively managed.
What the First 90 Days in AP Should Actually Look Like
The stabilisation period is not a time for optimisation. It is a time for controlled operation. Most post-go-live ERP activity is framed as improvement, when what AP needs is a narrow set of metrics confirming the system is processing correctly before any changes are made.
Three metrics are sufficient:
- Exception rate: the percentage of invoices requiring manual intervention before payment. If this is higher than the legacy environment after 30 days, the configuration or master data needs review, not additional training.
- Payment SLA adherence: the percentage of invoices paid within agreed terms. This is the vendor-facing signal, and it degrades faster than internal metrics suggest.
- Compliance filing continuity: confirmation that GST returns, TDS deposits, and MSME payment obligations are being met on time from live system data, not manually patched outputs.
Process ownership is the structural decision that determines whether these metrics improve or plateau. Finance controllers who wait for IT to resolve AP exceptions will find the queue grows faster than IT's bandwidth. The teams that stabilise fastest define, in writing, which exception categories finance resolves independently and which require IT involvement, and what the resolution SLA is for each.
Optimisation, covering configuration changes, workflow redesign, and automation of additional steps, should not begin until exception rates have returned to pre-go-live levels. Early optimisation in a destabilised environment compounds the original problem.
For a view of what AP controls should look like once the system has stabilised, see Accounts Payable Automation on SAP in India: What Goes Wrong.
If you are assessing whether your AP team is equipped to manage the post-go-live window, see how IQInvoice supports AP stabilisation after ERP go-live.
Key observations
- Exception rates commonly increase in the weeks immediately after ERP go-live; this is structural, driven by master data errors that legacy workflows absorbed invisibly
- India's regulatory calendar, covering GST filing cycles, TDS deadlines, and MSME payment obligations, runs concurrently with the stabilisation window and does not accommodate ERP transitions
- Process ownership ambiguity between IT and finance is the most common cause of AP backlog formation after go-live, not transaction volume
- Stabilisation and optimisation are distinct phases; configuration changes made before exception rates normalise compound rather than resolve the original problem
- Finance controllers who define exception resolution ownership and SLAs in writing stabilise AP faster than those who rely on informal escalation paths
Frequently Asked Questions
Why do accounts payable problems increase after ERP go-live?
What are the GST and TDS risks during an ERP transition in India?
How long does AP stabilisation typically take after ERP go-live?
Who owns accounts payable exception resolution after ERP go-live?
Published by IQInvoice IQInvoice is an AI-powered accounts payable automation platform for Indian mid-market finance teams.