Here’s a number worth sitting with: industry estimates put the cost of a single check transaction — printing, signing, mailing, the works — at over $2.25. The same payment made electronically through ACH runs under 15 cents.
Most finance leaders already know this. The gap isn’t awareness. It’s that knowing ACH is cheaper and actually getting there are two very different problems, and the second one is where most organizations quietly stall out.
IBM i has handled payment processing reliably for decades — check printing, remittance, basic reconciliation. The platform isn’t the issue. The question worth asking is whether the process wrapped around it has kept pace with how payments actually work today, or whether it’s still running on habits that made sense when electronic payment wasn’t a realistic option for most vendors.
If any of that sounds familiar, here are five signs worth paying attention to.
1. You Know the ACH Math, But Most Payments Still Go Out as Checks
This is the gap described above, made concrete. If someone asked what percentage of your outbound payments are electronic versus paper, and the honest answer is “less than we’d like” or “we’re not totally sure,” that’s not a knowledge problem — everyone in finance knows ACH is cheaper. It’s a process problem: nobody has made it easy enough to actually convert vendor by vendor.
The cost difference compounds fast. A company processing a few thousand payments a month isn’t looking at a rounding error between $2.25 and $0.15 per transaction — it’s a real, recurring number that shows up on a P&L every single month, indefinitely, for as long as the paper process stays the default.
2. Getting a Vendor onto ACH Is a Manual, One-by-One Slog
Here’s the part that actually explains sign #1: converting a vendor from check to ACH usually isn’t a system limitation — it’s a paperwork problem. Someone has to reach out, get banking details, verify them, set up the enrollment, and confirm the first payment actually landed correctly. Multiply that by however many vendors are still on paper, and it’s obvious why adoption stalls at “some vendors” instead of climbing toward “most vendors.”
If vendor ACH enrollment currently depends on someone manually emailing a form, waiting for a response, and hand-entering the result into your system, that’s hours of real labor standing between you and a meaningfully lower cost structure — for every single vendor, every single time.
3. Your Fraud Protection Is “We’d Probably Notice”
Check fraud isn’t a rare, theoretical risk — it’s the most common form of payment fraud organizations actually experience, precisely because checks are easy to intercept, alter, or counterfeit compared to electronic payments with built-in verification.
The real test: if a fraudulent check hit your account tomorrow, would it be caught automatically, before the money moves — or would it be caught eventually, after a bank statement review, by someone who happened to notice something odd? Positive Pay (matching issued checks against presented checks before they clear) is specifically built to close this gap. If your organization doesn’t have it, or has it for some accounts but not others, that’s a sign worth taking seriously, not a box to check someday.
4. Reconciling Payments Means Checking Multiple Systems by Hand
If confirming “did this payment actually go out, and did it land correctly” requires logging into your bank’s portal, cross-referencing your ERP, and maybe checking a separate spreadsheet somebody maintains — that’s not a minor inconvenience. It’s a sign that payment confirmation and payment execution were never actually connected to begin with.
This tends to be invisible day-to-day, because everyone’s used to doing it this way. It becomes very visible at month-end close, or whenever an auditor asks for proof a specific payment cleared and the honest answer involves checking three different places to be sure.
5. Nobody’s Fully Sure Which Vendors Are Enrolled in What
This is the sign that matters most, because it’s about risk compounding quietly rather than cost adding up visibly.
If there’s one person who knows, off the top of their head, which vendors are on ACH, which are still on checks, and which tried to enroll but never finished the process — that knowledge is doing the job a system should be doing. It’s genuinely useful today. It’s a real problem the day that person is out sick during a payment run, moves to a new role, or leaves the company entirely, and the rest of the team has to reconstruct from memory (or trial and error) something that was never actually documented anywhere.
The Real Question Isn’t Paper vs. Electronic
Every finance leader already agrees electronic payment is cheaper, safer, and faster to reconcile. The real question is why the conversion stalls out at “some vendors” instead of reaching “most vendors” — and the honest answer is almost always process friction, not lack of belief in the math.
That reframes what “fixing this” actually looks like. It was never a question of whether IBM i can handle modern payment processing — it already can. It’s a question of whether the manual steps standing between “we know ACH is cheaper” and “most of our payments are actually on ACH” have ever been properly addressed, or whether they’ve just been quietly tolerated because nobody had the time to fix them.
What This Looks Like in Practice
Organizations that make real progress here don’t treat it as a single big migration — they treat it as a few specific, fixable friction points:
- Start with your highest-volume vendors first. Converting the 20% of vendors who represent 80% of your payment volume moves the cost needle fast, without needing to solve every vendor relationship at once.
- Make enrollment self-service where possible, rather than a manual back-and-forth for every single vendor. The faster enrollment is, the less it depends on staff time to push it forward.
- Build fraud protection in as a baseline, not an upgrade. Positive Pay and similar safeguards are the kind of thing that’s much cheaper to have in place before an incident than to explain afterward.
Done this way, the shift from mostly-paper to mostly-electronic payments becomes a steady, measurable improvement — not a disruptive overhaul, and not something that requires touching the ERP or platform you already rely on.
If any of the five signs above sound familiar, it’s worth taking a closer look at where your payment process actually loses time and money today — not because the platform is the problem, but because the process wrapped around it usually hasn’t been revisited in years.
