Post-go-live AP backlogs split into two distinct types: stabilisation backlogs, caused by team adaptation gaps and configuration mismatches that resolve within 60 to 90 days, and optimisation backlogs, caused by structural process gaps that persist until deliberately addressed. Applying stabilisation fixes to an optimisation problem wastes capacity and delays recovery. The diagnostic question is not "how large is the backlog?" but "why is it still here at day 90?"
The first weeks after an ERP go-live feel the same regardless of the underlying problem. Invoice volumes spike in the exception queue, approvals stall, vendors follow up, and the finance team is in reactive mode. Most controllers treat this as a single problem, adding capacity and clearing the queue as the default response.
That framing works for roughly half the backlog. The other half does not respond to it, and continuing to apply the same approach past the 90-day mark is where post-go-live AP recoveries get stuck.
The distinction that matters is not volume or age. It is cause type. Backlogs caused by the transition itself behave differently from backlogs caused by structural gaps the ERP did not resolve. Mixing the two in the same queue creates accountability confusion and masks the real recovery timeline.
As covered in ERP Go-Live in AP: Why the Work Starts After the Switch, the go-live event opens a window of operational instability that is normal and bounded. What is not normal is when that instability does not close. The reason it does not close is almost always that two different backlog types are being managed as one.
What Stabilisation Backlogs Look Like and When They Clear
Stabilisation backlogs originate in the gap between how the system was configured during implementation and how the team actually operates once live.
The clearest signal is clustering. A stabilisation backlog produces a small number of repeating error types at high volume. GSTIN field mapping errors in the first batch runs. Approval routing built for an org structure that shifted between design and go-live. These failures are specific, traceable, and fixable at the configuration or master data level.
In SAP environments, a common stabilisation failure is the Plant-Business Place mismatch in multi-GSTIN companies. A manufacturer with registrations across 22 states but only four physical plants cannot route AP documents to the correct state GSTIN without state-specific Business Places assigned via OX18. If this mapping was not completed during implementation, every invoice routed through an unmapped location enters the exception queue. Volume is high, root cause is single, and the fix is a configuration correction, not a process redesign.
TDS rate mismatches at cutover follow the same pattern. As commonly understood under Section 194 of the Income Tax Act, different payment categories attract different withholding rates. Where vendor master migration leaves the "Liable" flag unchecked or misclassifies professional services under Section 194C instead of 194J, documents post at the wrong rate or skip deduction entirely. This is a data migration gap, not an AP process failure.
Stabilisation backlogs clear. The team adapts, configuration is corrected, and exception volume declines without requiring changes to how the AP process runs. By day 60, a well-run stabilisation effort produces a visible downward trend. By day 90, the queue should reflect only genuine process exceptions, not system-induced ones.
If the backlog is still flat or growing at day 90, it is no longer a stabilisation problem.
What Optimisation Backlogs Look Like and Why They Persist
Optimisation backlogs do not cluster. They present as a varied mix of exception types, each with a different root cause, none of which traces back to a cutover event. The team builds workarounds that become normalised, and the backlog plateaus.
Three-way match failures in manufacturing environments are the clearest example. Plants procure consumables locally without a system PO, creating direct-to-invoice flows that bypass the matching control entirely. Where POs do exist, split GRNs from partial shipments produce quantity mismatches against consolidated vendor invoices. Tolerance thresholds set loosely during implementation to avoid blocking production hide pricing discrepancies that accumulate quietly.
The India-specific dimension here is GSTR-2B timing. When a three-way match exception delays invoice posting in SAP past the vendor's actual filing period, the GST reconciliation for that period shows a gap. As typically interpreted under GST Rule 36(4), ITC claims are conditional on the supplier's return being filed. An invoice posted in SAP in October for a vendor who filed in September creates a mismatch that requires manual reconciliation, not a system fix.
Multi-GSTIN routing failures that were not addressed during stabilisation become optimisation problems if left past day 90. At that point, the team has built compensating workflows around the gap. Fixing it requires both a configuration change and a process change, because the workaround has become embedded.
Take every invoice that has been in the exception queue for more than 30 days. Ask one question for each: can this exception be attributed to a cutover-induced cause? If yes, it is a stabilisation item with a configuration or data fix. If no, it is an optimisation item requiring a process decision.
For a framework on classifying exception types by source and risk, the AP Exceptions Taxonomy: Classifying by Source and Risk provides a working structure that applies directly to this classification exercise.
How to Assign Ownership and Sequence the Fix
Stabilisation and optimisation backlogs require different owners and different timelines. Treating them as one queue obscures both.
Stabilisation is owned by the implementation team or system integrator. The fixes are configuration corrections and data remediation, measured in days to weeks. If the implementation partner has already rolled off, this work needs to be scoped and reengaged explicitly, because the finance team does not have the system access or mandate to make configuration changes unilaterally.
Optimisation is owned by the finance controller. The fixes are process redesign decisions about PO coverage policy, vendor onboarding requirements, and approval matrix alignment. These require authority over how the AP function operates, not just system access. The timeline is weeks to months, and the sequencing matters. Redesigning a process that is still in stabilisation produces a design based on abnormal operating conditions.
The practical checkpoint is a backlog classification exercise at day 60. Pull every aged invoice, assign each to one of two categories, and report the split to leadership. This single exercise reframes the recovery conversation from "why is the backlog still large?" to "how much of this is our problem versus the implementation's problem?" It also creates the accountability structure for the optimisation work that follows.
For context on how post-go-live ERP environments degrade when this distinction is not made, Why AP Automation Doesn't Sustain Invoice Cycle Time Gains covers the pattern in detail.
Finance controllers who have completed the classification exercise and identified a structural optimisation backlog can request a walkthrough with the IQInvoice team on where AP automation fits into the resolution sequence.
Key observations:
- Post-go-live AP backlogs are not a single queue. Stabilisation backlogs and optimisation backlogs have different causes, different owners, and different resolution timelines.
- A stabilisation backlog that is still flat or growing at day 90 has become an optimisation problem and will not resolve without deliberate process intervention.
- In Indian SAP environments, multi-GSTIN Plant-Business Place mismatches and TDS vendor category gaps are the most common stabilisation failures; three-way match coverage gaps and GSTR-2B timing mismatches are the most common optimisation failures.
- Mixing both backlog types in the same queue creates accountability gaps where neither the implementation team nor the finance function takes full ownership of resolution.
- The backlog classification exercise at day 60 separates what the implementation team must fix from what the finance controller must redesign.