Answer
The clearest sign this has crossed from inconvenience into risk is when the same reconciliation breaks in a different way every month, requiring someone experienced to diagnose it fresh each time rather than following a repeatable checklist. Common examples on IBM i include bank feeds that do not match automatically because of formatting differences, subledger totals that drift from the general ledger after a manual journal entry corrects a posting error, and inventory or job cost data that has to be exported and re-keyed into a separate reporting tool because the two systems were never designed to talk to each other.
Buyers should quantify this before shopping for a fix: how many hours per close cycle go into manual reconciliation, how many of those hours are spent finding the discrepancy versus actually fixing it, and how often a reconciliation issue delays the close past its target date. That number makes the business case concrete and also helps distinguish between problems that stronger native controls inside the current ERP could solve, such as better matching rules or automated subledger posting, and problems that genuinely require a separate platform or a proper middleware layer between systems. Fixing the wrong layer wastes budget and leaves the actual bottleneck in place.