Glossary · Payments

ACH payment: definition and how it works in accounts payable

An electronic bank-to-bank payment in the United States sent through the Automated Clearing House network, widely used for paying suppliers.

Definition

An electronic bank-to-bank payment in the United States sent through the Automated Clearing House network, widely used for paying suppliers.

Also called: ACH, direct deposit to vendor, EFT (US)

What it means

An ACH payment is an electronic bank-to-bank payment in the United States sent through the Automated Clearing House network. AP teams also call it ACH, direct deposit to vendor, or EFT (US). The money moves from your company's bank account to the supplier's bank account with no check and no card, and the supplier sees a deposit rather than a paper item to collect.

The naming matters because the rails are country-specific. ACH is the US network; other countries run their own local systems, with their own naming, cutoffs and return rules. Companies paying cross-border vendors often find the same supplier is paid by ACH from one entity and by a local transfer from another, and the two do not reconcile alike. Rules also differ by company: some AP teams release ACH only in a scheduled run, others release individual payments on approval.

There are two directions to keep straight. An ACH credit pushes money to the supplier, which is what most people mean by an ACH payment to a vendor. An ACH debit pulls money from your account, and it should happen only where the supplier has an authorization on file. Both appear in AP and both belong in the same reconciliation.

Because the vendor record carries the bank details, an ACH payment is only as reliable as that record. The invoice tells you what is owed; the vendor record tells you where the money goes. Most of the failures below start in the gap between the two.

How it works in practice

A supplier is onboarded and its bank details are captured on the vendor record: bank name, routing details, account details, and the currency and country if the vendor is paid from more than one entity. Those details should be confirmed with the supplier through a contact and a phone number you already had, not through the paperwork that arrived asking for the setup. The vendor record also holds the payment method, and that method decides whether an invoice goes into the ACH file or the check queue.

At payment time, approved invoices are picked up in the payment run, grouped with other payments to the same supplier, and sent to the bank as a file. The bank processes it on the network's schedule, the supplier's bank posts the deposit, and a remittance advice tells the supplier which invoices are being paid. The AP side is not finished when the file leaves: the invoices must be closed against the payment, and the bank statement must later show the same payment clearing.

Timing matters more than it looks. The date the supplier receives funds is set by the network's processing schedule and your bank's cutoff, not by the moment someone in AP presses send. When a supplier offers a discount for payment by a certain date, that date should be measured against when the money actually lands. Whether the discount is worth taking is a financing question: compare the rate implied by the discount with your own cost of funds, and remember a missed discount is money lost the same way a duplicate is.

A clean process keeps the payment method and the payment record aligned. If a supplier moves from check to ACH, retire the old method on the vendor record at the same time, and cancel any check already queued or printed before the ACH goes out.

Where it goes wrong

The most expensive failure is a changed bank detail. A request arrives asking AP to update the supplier's account, sometimes from a compromised supplier mailbox so the thread looks genuine, sometimes from a lookalike address. The vendor record is updated, the next run pays the new account, and the real supplier later says it was never paid. Confirm any change through a known contact, using a phone number you already had, and never through the email that requested the change or a number printed in it. A second person should review the change before it is saved.

The second classic is the duplicate created by a method change. A supplier that used to be paid by check moves to ACH. The ACH is set up and paid while a check for the same invoice is still in the queue or was already mailed. Or the payment is returned for bad account details, AP reissues by check, and the original ACH posts later. Both leave the supplier holding two payments for one invoice, and neither shows up as an exception unless someone looks.

Stale details are quieter. A closed account or a transposed digit produces a return, and the invoice sits open while the supplier's statement shows nothing received. If AP reissues without holding the invoice, the return and the reissue become a duplicate once the original settles. Vendor credits get lost in the same shuffle: when a supplier changes method or entity, credits sitting against the old account go unapplied while AP keeps paying new invoices in full.

None of this is caught by the approval workflow, because the invoice was legitimate and approved. It is caught by watching the vendor record and the payment file, which is a separate control.

What to check

Before saving any bank detail change, confirm it with a known contact and record who confirmed it and when. Have someone other than the person who keyed the change review it. The requester should never be the only source of the new account details.

At the payment run, review for suppliers with a bank detail change in the recent period, suppliers with more than one payment in flight, and any supplier whose payment method changed recently. Look at the account the money is going to, not just the amount.

After the run, reconcile the bank statement to the payment file, and treat every return as an open item that blocks reissue until it is resolved. Where a payment was reissued, check whether the original later cleared. At the bank, use the ACH controls available to you, including positive pay or blocks on ACH debits you did not authorize, and confirm with your bank which ones apply to your accounts.

Keep the remittance and the bank confirmation with the payment record, so a supplier query or a controller's review can be answered from one place. When a supplier disputes a payment, check the vendor record history first: the answer is usually in what changed and who approved it.

Questions

Is an ACH payment the same as a wire?

No. A wire is a different bank transfer with its own cutoffs and its own recall rules. An ACH payment runs through the Automated Clearing House network and is usually batched with other payments. Ask your bank about timing and recall for each, since the rules differ.

A supplier emailed to change their bank details. What should I do?

Do not update the vendor record from that email. Call a contact and a number you already had on file, confirm the change, and have a second person review it before the next payment run. Treat urgency in the request as a reason to slow down, not to skip the call.

Why did a supplier get paid twice after switching from check to ACH?

Usually because the old method was never retired. A check for the same invoice was still queued or already mailed when the ACH went out. Review suppliers with a recent method change for more than one payment in flight before each run.

Updated Nov 6, 2026. Figures on this page are calculated by ERPSav from the definitions shown. The explanatory text is drafted with AI from those figures and checked automatically before it is published. General information only, not legal, tax or financial advice.