Skip to content
RYAN BRENTS / WRITING / ROSS-ERP-ACH-BANKING-INTEGRATION
LIVE · ATL
THE LEDGER — /WRITING/ROSS-ERP-ACH-BANKING-INTEGRATION
← BACK TO THE LEDGER

You're moving real money out of Ross with a hand-built file and a held breath

NACHA files keyed by hand, payments typed into a bank portal, statements reconciled by eye. Every step is real money and one typo from the wrong account. It doesn't have to be.

filed: 2026-11-06 · topic: ROSS ERP · read: 7 min

Here is a process that happens at a lot of companies and should make everyone slightly nervous. It's payment day. Someone pulls the payables from Ross, assembles a NACHA file by hand — or worse, types the payments into the bank's web portal one at a time — double-checks the account numbers with the specific intensity of a person who knows what happens if they're wrong, and hits submit. Then they email the remittance advices separately, from a different system, and hope the two match. At month-end, another person reconciles the bank statement against Ross by eye.

Every step of that is real money, and every manual step is one typo away from sending it to the wrong place. You're moving money out of Ross with a hand-built file and a held breath — and unlike most integration problems, the failure mode here isn't a chargeback or a stale number. It's funds in the wrong account and a very bad phone call.

Why this one deserves more respect than the others

Most of the integrations I write about fail quietly and cost you slowly. Banking fails loudly and costs you immediately.

An oversold web order is embarrassing. A wrong tax rate is an assessment. But a fat-fingered ACH file moves actual money to an actual wrong account, and money is dramatically easier to send than to get back. Add in the fact that payment systems are exactly where fraud goes looking — business email compromise, altered vendor bank details, the whole genre — and you have a process where "we do it carefully by hand" is not the reassurance people think it is. Careful humans are still humans, and they do this at 4:30 on a Friday too.

What a real banking integration does

The point of connecting Ross to your bank isn't just convenience — it's removing the manual seams where money goes wrong. Done properly, it covers both directions and the reconciliation in between.

On the outbound side, it generates the payment files — NACHA ACH for vendor payments — directly from approved payables in Ross, so nobody's hand-building a file or re-keying account numbers into a portal. On the inbound side, it takes customer ACH receipts and applies them into AR, matching them to the right invoices instead of leaving someone to puzzle out which payment covered what. And underneath both, it reconciles: the bank's activity against Ross, automatically, so month-end reconciliation stops being a multi-day squint at two screens.

Close the remittance loop

This is where it connects to something you may already have solved. If your remittance advices are being emailed automatically — the way the CFB document automation sends them — then the payment and the advice should be coming from the same source of truth, not two systems that happen to agree most of the time. The vendor gets paid, and gets a matching remittance that actually ties to the payment, because both came from the same approved record in Ross. When the payment and the advice drift apart, you get the vendor calling to ask what the deposit was for, which is a small thing that happens a surprising number of times a month.

The security is not optional here

I do security work, and this is the integration where I'm least willing to hand-wave it, because it's the one an attacker most wants to reach.

A banking integration has to be built with real controls: approval workflows and dual control so no single person (or single compromised login) can move money alone, encryption of the files and credentials, and positive pay so the bank rejects anything you didn't actually authorize. Vendor bank-detail changes need to be treated as the high-risk events they are, not a routine field update, because "please update our banking info" is the entire plot of most payment fraud. Automating payments without wrapping them in these controls doesn't just move the risk — it speeds it up. The right build makes the process both faster and safer, which is the only version worth doing when the payload is money.

Reconciliation: get your month-end back

The least dramatic benefit is the one your accounting team will thank you for. When the bank's activity flows back and matches against Ross automatically, reconciliation stops being a ritual and becomes a report with a short list of genuine exceptions. The exceptions are where the humans should be looking anyway; the thousand transactions that matched cleanly don't need a person to confirm they matched. That's the whole promise of automation in finance — not replacing the judgment, just deleting the part where someone manually agrees with two systems that already agree with each other.

The bottom line

Moving money in and out of Ross by hand isn't diligence — it's exposure with good intentions. Generate the payment files from approved payables, apply receipts automatically, close the remittance loop, reconcile the bank against Ross without the monthly squint, and wrap all of it in the controls a money system actually requires. It's the integration where getting it right matters most, because it's the one where getting it wrong writes a check you can't uncash.


If payment day at your company involves a hand-built file and a held breath, this is a high-value, high-relief thing to fix — and the security side is exactly where I live. Let's talk →. Related: your ERP already made the invoice.

READ NEXT
NEWER — none, this is the latest
By Ryan Brents →

learned it the hard way so you don't have to — one email starts it

NO CALENDAR LINKS · NO FUNNEL · JUST MAIL