The payment layer is decided by default
Payments is rarely a line item in a modernization business case. It is assumed - that the new system will handle it, that the provider will make it work, that the integration partner has it covered.
Each of those parties knows their own half. None of them owns the span from invoice to close.
So the requirements get set by whoever happens to be in the room when the question comes up, and the gaps surface eighteen months later as manual work that nobody planned for and nobody is measuring.
The cheapest time to ask what payments needs is before the architecture is fixed. The second cheapest is now.
Payments do not break in the middle. They break at the handoffs.
Money moves through your business in a sequence. It is invoiced, it arrives, it settles, it gets matched, it posts, it gets reported, and the exceptions go somewhere. Each step usually works.
The damage happens between them. A reference that existed at the start does not survive to the ledger. A field gets stripped moving between systems. A decision gets made in an email thread and is not retained. By the time anyone notices, the fix is manual and the cost is invisible because it is spread across people who are used to it.
Invoice to close is the span. The handoffs are where the work is.
I spent thirty years on the other side of the contract you are trying to get out of.
Most people advising you on payments have either sold payments or examined them. I did the first for three decades, at Global Payments Canada, at PSiGate, at Bell, building the channel relationships and the integrations that businesses like yours are now living inside.
Which is why I can tell you what actually breaks if you leave your provider. Your provider will not. The one trying to win you will understate it. Your ERP partner knows their half. It is a short list of people who can answer that question honestly, and being on it is the only real credential I have.
I started as a credit officer. The job teaches you one thing: when the numbers do not close, go and find out why.
What one flow can and cannot tell you
The Diagnostic examines one flow properly rather than all of them superficially. That is a deliberate trade, and it has a consequence worth stating before you buy anything.
The findings document separates three things and labels them:
- What is established within the flow examined. Evidenced, and the evidence is shown.
- What it suggests about the rest of the business. Reasoned inference, named as inference rather than as finding.
- What would require broader work to answer. Stated plainly, including what that work would involve.
One flow does not set your modernization priorities. It gives you one properly evidenced input, and an honest account of what it does not cover.
