ACH Wire Instructions: Required Fields and a Verification Checklist
ACH and wire instructions are separate sets of banking details, not a single payment method. Use these field templates and verification controls to build payment-ready recipient records.
ACH wire instructions should specify either ACH or wire transfer—not leave the payment method ambiguous. For a U.S. ACH credit, collect the recipient’s account-holder name, bank name, ACH routing number, account number, and account type. For a wire, obtain the bank’s wire-specific instructions, including beneficiary details, the applicable bank identifier, and any intermediary or further-credit information.
The same account may accept both methods, but its ACH and wire routing numbers may differ. Never assume that details copied from a check or a previous ACH payment are valid wire instructions.
For finance teams managing international recipients, the practical challenge is turning documents and emails into verified, rail-specific records. This guide provides a collection template and a release checklist—not a substitute for the receiving bank’s instructions.
Start with an explicit payment-method label
ACH and wires are distinct payment methods. ACH processes electronic credits and debits through the U.S. Automated Clearing House network; wires use separate banking infrastructure. Plaid’s ACH-versus-wire overview explains the underlying distinction.
A request labeled “ACH/wire details” is therefore incomplete. Before entering banking information, ask the recipient to identify:
- Payment method: U.S. ACH credit, U.S. domestic wire, international wire, or a specific local transfer method.
- Receiving country and currency: Where the account is held and which currency it can receive through that method.
- Account-holder identity: The name on the receiving account, which may differ from a trading name.
- Special handling: Any intermediary bank, collection-account restriction, or mandatory reference.
Do not use a single routing-number field shared across every payment method. A recipient should be able to maintain separate ACH and wire instruction sets without one overwriting the other.
Required fields for ACH and wire instructions
The following is a collection checklist. Exact requirements vary by bank, payment provider, destination, and account structure. Follow the receiving bank’s instructions and the sending provider’s field requirements.
| Field | U.S. ACH credit | U.S. domestic wire | International wire | Operational check |
|---|---|---|---|---|
| Account-holder name | Collect | Collect | Collect | Resolve trading-name differences |
| Bank name | Collect | Collect | Collect | Match bank identifiers |
| Routing or bank identifier | ACH routing number | Wire routing number | SWIFT/BIC and local codes as required | Validate for the selected method |
| Account identifier | Account number | Account number | IBAN or account number as applicable | Preserve leading zeros |
| Account type | Checking or savings | As requested | As requested | Confirm supported account type |
| Beneficiary and bank addresses | As requested | As requested | Commonly requested | Use required structured fields |
| Receiving currency | USD for standard U.S. ACH | Confirm USD instructions | Confirm supported currency | Identify conversion requirements |
| Intermediary and further-credit details | Only if explicitly supported | If instructed | If instructed | Keep each party separate |
| Payment reference | Invoice or recipient reference | Invoice or recipient reference | Reference or purpose details as required | Distinguish optional from mandatory |
ACH credit instruction template
Use the following labels in a secure collection form. These are fields to complete, not sample banking coordinates.
- Payment method: U.S. ACH credit.
- Account-holder legal name: Name registered on the account.
- Bank name: Receiving financial institution.
- ACH routing number: Bank-confirmed routing number for incoming ACH credits.
- Account number and type: Enter separately; retain leading zeros.
- Remittance reference and contact: Invoice-matching information and a contact for payment questions.
- Instruction source and effective date: Where the details came from and when they should apply.
Receiving an ACH credit is not the same as authorizing an ACH debit. If your business intends to pull money from an account, account details alone are not sufficient authorization.
Wire instruction template
- Payment method: U.S. domestic wire or international wire.
- Beneficiary: Account-holder name, address, and account number or applicable IBAN.
- Beneficiary bank: Name, address, and the wire routing number or applicable SWIFT/BIC and local bank codes.
- Currency: Currency covered by these specific receiving instructions.
- Intermediary bank: Details exactly as supplied, when required.
- Further credit to: Ultimate recipient name, account identifier, and reference, when required.
- Payment reference or purpose: Required destination information and invoice reference.
Keep intermediary-bank details separate from beneficiary-bank details. Likewise, a further-credit identifier is not automatically the beneficiary account number. Confirm how the sending bank maps these instructions into its payment form.
Validate the routing number without overstating what validation proves
U.S. ACH and wire routing numbers use the same nine-digit format, but format alone does not establish that a number supports the intended payment method. Some banks use the same number for both; others use different numbers. This routing-number comparison describes that distinction.
Apply separate checks rather than treating “valid bank details” as a single result:
- Format: Does the identifier meet the applicable structural requirements?
- Routing: Does the institution support the selected method through that identifier?
- Account relationship: What evidence connects the account to the intended recipient?
- Authority: Was the person supplying or changing the instructions authorized to do so?
A valid routing number does not prove account ownership. A successful small test payment demonstrates reachability, not necessarily the legitimacy of the person requesting the change. Use such checks as evidence with defined limitations.
Handle international recipients without forcing U.S. fields
Recipient location and receiving-account location are different facts. An overseas contractor may provide U.S. receiving details, while a U.S. supplier may request payment to a foreign account.
Ask which payment methods the specific account supports. A provider-issued USD collection account may have restrictions on payer types, currencies, or incoming transfers. USD denomination alone does not establish ACH eligibility.
For foreign accounts, collect destination-specific identifiers rather than requiring a U.S. routing number. IBAN is not universal, and SWIFT is a messaging network—not a guarantee of a direct bank-to-bank settlement path. International wires can involve intermediary institutions.
Cross-border arrangements can also raise International ACH Transaction classification questions. Ask the originating bank how it classifies the arrangement rather than deciding solely from the presence of U.S. account details. For choosing the delivery method, use a separate local-rail versus SWIFT routing policy.
Make instruction changes invalidate payment readiness
The highest-risk moment is often not initial onboarding but a later request to replace approved banking details. A plausible invoice attachment or familiar email thread is not independent verification.
Nacha’s guidance on expanded fraud-monitoring responsibilities describes risk-based processes for detecting fraudulently initiated ACH entries. Treat that as a reason to examine the complete workflow, not as proof that one particular verification service is universally required.
Use this change-control sequence:
- Collect securely: Use an authenticated channel rather than circulating bank details in shared spreadsheets. Payouts.com’s Vendor Portal supports self-service vendor onboarding.
- Verify independently: Contact an authorized recipient representative through previously established details—not a phone number supplied in the change request.
- Separate responsibilities: Have someone other than the editor approve the banking change.
- Version the instructions: Retain the previous record, new record, verification evidence, effective date, and approver.
- Recheck queued payments: Hold affected payments until approval covers the new destination.
Useful design rule: bind payment approval to an instruction version, not just a vendor ID. Otherwise, an approved invoice can silently inherit a newly edited destination.
Hypothetical example: a valid change that still needs a hold
A supplier changes its wire account after an invoice is approved but before payment release. The new details are independently verified. Even so, the queued payment should not automatically switch destinations: its approval referenced the previous instructions. Revalidate the payment against the approved replacement record, then release it with an audit trail.
Final checklist before releasing payment
- The payment method is explicit, not labeled only “ACH/wire.”
- The routing details are appropriate for that method.
- The account-holder name, receiving currency, and account restrictions are resolved.
- Required intermediary, further-credit, and reference fields are mapped correctly.
- Recent changes have independent verification and approval.
- The queued payment uses the approved instruction version.
- No earlier attempt remains unresolved before a replacement is submitted.
If a payment fails, preserve the original instructions, provider reference, and failure message. Do not simply switch methods or resend: first establish whether the original payment was rejected, returned, or remains pending.
The next step is to audit your recipient form and payment-release logic against this checklist. When evaluating Payouts.com Payouts Automation, use these requirements to discuss how instruction collection, approval, execution, and reconciliation should connect. Good instructions are not merely complete bank details; they are bank details approved for a specific recipient, method, currency, and payment.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
30 commentsRelated resources
Local Payment Rails vs SWIFT: Build a Corridor Routing Policy
The right payout route depends on the recipient’s currency, bank reachability, funding, and payment purpose—not just the transfer fee. Here is how finance teams can turn that decision into a repeatable corridor routing policy.
Cross-Border Payments in Latin America: Country Readiness Guide
Latin America’s domestic payment networks can deliver fast local payouts, but the cross-border operation still depends on funding, FX, and country-specific data. Build a country readiness matrix before promising recipients a delivery time.
CJ Affiliate Account: Setup, Payment Access, and Controls
A CJ Affiliate account connects publishers and advertisers, but account access does not mean commissions are ready to spend. Here is how to separate registration, program approval, payment eligibility, and bank receipt.
Run your entire money cycle on one ledger
Global payouts, AP/AR automation, and AI agents with their own wallets and spend limits.
Get started
The 'authority' check you mention is the most under-documented part of vendor master governance. We validate format and routing automatically but still rely on manual approval workflows for any banking change, which creates a bottleneck. How are teams actually operationalizing the 'who authorized this change' verification without just defaulting to email trails that anyone can spoof?
We split authorization into two controls: one for the relationship owner (procurement or the business unit) to confirm the change is expected, and a second for treasury to verify it passes format and routing checks. Neither is sufficient alone, but together they catch both fraud attempts and legitimate mistakes before release.
We added a dual-authorization requirement for banking changes—original contact confirms via callback, then procurement or legal signs off based on relationship length and dollar exposure. Still manual but at least there's a documented control owner for each step.
The advice to ask recipients for explicit payment-method labels before collecting details sounds obvious but we only started doing it six months ago after multiple routing-number mismatches. Before that we had a single 'Bank Details' section in our vendor portal and suppliers would paste whatever was on their letterhead.
Same issue. We ended up splitting the vendor portal into separate workflows—one for ACH, one for wire—because people would copy the same routing number into both fields even when we labeled them differently. Now they have to consciously pick a method before they see any form fields.
We did the same refactor last year and the submission error rate dropped by about half. The downside is now we have vendors who submit both sets of instructions but then only update one when their banking changes, so we added version tracking per method.
The point about intermediary vs. beneficiary bank fields is where we see the most errors in practice. Vendors copy-paste everything into a single block of text and we end up manually parsing out which SWIFT code belongs to which institution. Treating them as separate required fields in the UI would force clarity upstream instead of leaving it to AP to interpret.
We built a structured intake form that splits intermediary and beneficiary into separate card-style sections with explicit labels: 'Bank 1 (Intermediary)' and 'Bank 2 (Beneficiary Bank)'. It cut our clarification emails by about half since vendors can't just dump everything into one box anymore.
We force separate dropdowns in the payment form now—one for intermediary bank name and SWIFT, another section entirely for beneficiary bank. Still doesn't stop people from entering the same code twice or flipping them, but at least the structure makes it harder to dump everything into one field.
The distinction between format validation and account ownership validation is critical and something we still struggle to communicate internally. Our treasury team treats a successful routing lookup as proof of legitimacy, but AP has seen three attempted frauds this year where the routing number was valid but the account either didn't exist or belonged to someone other than the stated vendor.
We solved this by splitting validation into two workflow stages: automated format/routing checks run immediately, but ownership verification requires a callback plus a micro-deposit confirmation before the record goes live. Treasury sees the routing validation as a gate, not a conclusion.
We stopped treating routing validation as a control altogether and moved it into data quality checks instead. The fraud signal comes from change timing, request source, and beneficiary name mismatch—routing lookup just confirms we won't bounce the file.
The template approach is helpful but we still see vendors confusing further-credit-to fields with intermediary bank details constantly. Any suggestions on how to frame the collection request so they understand the difference before we get incomplete wire instructions back?
We include a visual diagram in the collection form showing funds flowing from our bank → intermediary (if applicable) → beneficiary bank → final account holder. It doesn't eliminate all confusion but reduces the back-and-forth significantly when the vendor can see the flow mapped to the actual form fields.
We started labeling it in our collection form as "Intermediary = bank in the middle, Further credit = final recipient if different from you." Then added a conditional help text that only shows the further-credit section when intermediary is populated. Cut our incomplete instruction rate by maybe half but you're right that vendors still mix them up regularly.
The distinction between ACH and wire routing numbers being different even for the same account caught us during a payment-run audit last quarter. We'd been using whatever routing number vendors sent us without asking which method it was intended for, and ended up with about a dozen failed wires that had to be manually corrected and reissued. Now we collect separate instructions per method, but vendors still push back on filling out two forms.
We had the exact same issue but caught it earlier—vendor gave us one routing number without specifying method, and our treasury analyst happened to call the bank to verify before releasing a large payment. Turned out the number was ACH-only and would have bounced as a wire. Now we explicitly label the method when we collect details, which the article recommends but honestly feels like something that should be obvious and still trips everyone up.
We caught this the hard way too. Now we explicitly ask vendors to label their instructions "for ACH" or "for wire" and refuse to process anything that just says "routing number." The templated intake form in the article is basically what we built after that mess.
The checklist itself is useful but the bigger operational issue is enforcement. We've built the separate ACH/wire fields, we've updated the vendor form, we still get a PDF with one routing number and "use for all payments." How are people actually getting vendors to fill this out correctly without a three-email back-and-forth every time?
We require vendors to complete a web form instead of accepting PDFs. The form has separate conditional sections based on which payment method they select. If they choose both ACH and wire, both sections unlock and require separate routing fields. Doesn't eliminate pushback but at least makes the distinction unavoidable.
We added a hard stop in the vendor portal that blocks submission unless both method fields are populated or one is explicitly marked N/A. Cut down incomplete forms by about 70% but you still get people who just duplicate the same routing number in both boxes to get past the validation.
The point about not assuming check details are valid wire instructions is something we learned the hard way. A vendor gave us their deposit slip info and we used it for an urgent international wire—bounced back three days later because the routing number only handled ACH. Cost us fees and a very awkward conversation with their finance team.
We had a similar issue but in reverse—vendor sent wire instructions, AP used them for ACH because the routing number format looked right. Cleared eventually but took forever and we had no idea where it was for days. Now we make vendors explicitly label the method on the form itself.
Same exact scenario except ours sat in limbo for a week while the intermediary tried to figure out what to do with it. The vendor was furious but they're the ones who sent us a voided check image when we explicitly asked for wire instructions. Now we refuse to process any wire over 10k without a signed bank letter.
The separate field requirement for ACH vs wire routing is spot on but creates a UI problem—most ERP vendor modules still have a single "routing number" field that gets reused across payment types. We ended up building a custom table just to store method-specific instructions because NetSuite's native beneficiary record couldn't distinguish between the two.
We hit the same wall with SAP and ended up doing method-specific beneficiary master records instead of trying to overload the bank key field. The downside is now we have duplicate vendor records for anyone we pay both ways, which creates its own reconciliation headaches.
We hit the same wall with SAP and ended up doing method-specific beneficiary master records with workflow rules to prevent cross-contamination. The real pain is when someone updates ACH details and your wire team finds out mid-payment that they've been overwritten.
Curious how others handle the authority validation piece mentioned at the end. We require dual sign-off on any banking detail changes in our vendor master file, but that doesn't solve the problem when the initial email request comes from a compromised account. Are people using out-of-band verification calls for every change, or only above certain payment thresholds?
We use a callback to a pre-registered phone number for any banking detail changes over a certain dollar threshold. Still not perfect because the vendor contact database itself can be stale, but it's caught two attempts in the last year where the email was legit but the person's credentials had been compromised.
We do callbacks to a known contact plus require a signed W-9 update when banking details change. Still not foolproof but adds friction. The problem is balancing security theater vs actual control—most compromised email cases I've seen succeed because the fraudster has full mailbox access and can intercept the callback too.