THE IDEA TO TAKE WITH YOU

An ACH credit sends money towards a receiving account; an ACH debit collects from an authorised account. Permission to receive a credit does not mean your product supports debit collection, recurring billing, or every payer type.

A client says it can pay by ACH. A software form asks you to connect a bank account for ACH debit. Your receiving provider lists ACH credits.

All three mention ACH, but they may describe different sides of a transaction.

ACH credit and ACH debit differ in who initiates the instruction and whether it pushes money to an account or collects money from one. That difference affects authorisation, setup, product support, and how a problem is investigated.

This guide explains the distinction for businesses and independent professionals receiving or making USD payments. It does not provide an ACH origination implementation or replace the applicable bank, provider, and network rules.

Start with the direction of the instruction

For an ACH credit, the originator initiates an instruction that credits the receiving account. A business paying a supplier through its bank can be an example.

For an ACH debit, the originator initiates a collection from the receiver’s account under an applicable authorisation. A business collecting an authorised payment from a customer can be an example.

Nacha’s developer guide describes ACH participants, entry types, and the distinction between credits and debits. The actual rights and requirements depend on the entry and account context. Nacha: How ACH works.

The customer’s screen may simply say “bank payment.” Ask what is actually being initiated before deciding which receiving details or authorisation process applies.

Compare credits and debits in practical terms

QuestionACH creditACH debit
General directionMoney is sent towards the receiving accountMoney is collected from the authorised account
Common business exampleClient sends payment for an invoiceCustomer authorises a provider to collect an amount
Key setup issueCorrect receiving instructions and permitted payerValid authorisation and a supported debit arrangement
Recurring useMay involve repeated or scheduled sendingMay involve authorised recurring collection
Important limitationReceiving support does not prove support for every payer or usePossessing account details does not create permission to debit

“Push” and “pull” are useful shorthand, but they do not describe every contractual or technical detail. Use them to orient the discussion, then confirm the actual product and transaction.

Follow an invoice paid by ACH credit

A fictional consultant invoices a US business for USD 1,500. The consultant supplies current receiving instructions explicitly supporting the client’s ACH credit payment.

The client’s authorised finance team initiates the payment through its bank or service. The sending provider processes the instruction, and the receiving side identifies and allocates the funds under its procedures.

The consultant records the payment against the invoice once the relevant status is confirmed. Any receiving fee is recorded separately from the gross payment.

This does not mean the consultant has permission to take money from the client’s account. The client initiated the sending arrangement; the consultant supplied a supported destination.

Follow an authorised ACH debit collection

In a different fictional arrangement, a customer agrees to pay a business through a provider offering ACH debit collection. The provider requires the relevant authorisation and account verification before collecting.

The business or provider initiates the debit according to that arrangement. It is not merely reusing the customer’s account number as a receiving address.

The authorisation needs to match the applicable rules and payment context. Nacha’s guidance describes requirements for compliant authorisations, including different considerations for consumer and business accounts. Nacha: Compliant ACH authorisations.

Do not copy a generic sentence into an invoice and assume it authorises recurring collection. Use the provider’s approved process and appropriate legal review for the actual arrangement.

Receiving details do not automatically support debit collection

A payment platform can issue USD receiving details that accept supported incoming credits without offering a merchant ACH debit product.

It may also restrict attempted debits against those receiving details. Using them to pay subscriptions, connect a third-party account, or complete a verification flow may be unsupported.

Ask the provider which directions and use cases are permitted. “ACH supported” is incomplete unless it identifies the relevant activity.

For Ostro, use only the capabilities and instructions available in the workspace. This article does not claim that Ostro offers ACH debit origination, automated subscription collection, or unrestricted debit access to receiving details.

A recurring invoice is not an automatic debit

A monthly retainer can be paid through a new ACH credit each month, a payer-controlled scheduled instruction, or a separately supported authorised debit arrangement. The commercial schedule does not decide the mechanism.

If the client must initiate each payment, say so in the handover. Do not tell the client that the invoice will be collected automatically unless the required product and authorisation are in place.

If an authorised recurring collection changes in amount or timing, follow the applicable notice and authorisation requirements through the provider. Avoid treating an old permission as unlimited authority for unrelated future charges.

The retainer and milestone guide explains how to keep the contract’s billing schedule separate from the payment method.

Confirm the account and payer types

Consumer and business accounts can have different requirements and protections. A particular receiving arrangement can also distinguish first-party funding, employer payments, business client payments, and other third-party transactions.

Do not label a business transaction as personal to fit a form or avoid a provider restriction. Describe the actual parties and purpose.

A provider accepting a transfer from an account you own does not prove it accepts payments from every client. Likewise, a supplier providing ACH details does not prove your chosen provider can use them for the intended transaction.

For an international recipient, eligibility for the receiving service is another separate question. Local USD instructions do not remove jurisdiction, onboarding, or monitoring requirements.

Keep account verification separate from payment permission

A provider may use a supported verification process to establish information about an account. That process should not be confused with permission to initiate every future transaction.

Check whether microdeposits or a third-party account-connection service are supported for the particular account arrangement. A virtual receiving product may handle verification differently from a conventional bank account.

Use the actual verification information supplied through the approved process. Do not guess microdeposit amounts or invent a code to pass a check.

Also protect the account’s credentials. Share them only within a legitimate, understood authorisation flow where appropriate, and never send passwords or one-time codes to a client as payment instructions.

Do not confuse ACH debit with an ACH receiving fee

A receiving fee deducted by your provider is not necessarily an ACH debit initiated against your bank account. It can be an internal charge applied under the service’s terms.

Similarly, a debit on your statement can simply mean money left the account; that accounting description does not establish the network or transaction type.

Use the provider’s detailed transaction record to identify the payment method. Labels such as “debit,” “withdrawal,” or “bank transfer” in a summary view may be too broad for troubleshooting.

Keep the gross amount, fee, and resulting balance separate in your records. See payment reconciliation for the broader ledger process.

Compare timing using the actual service

ACH includes different processing arrangements, including eligible same-day and other scheduled processing. The sender’s service, submission windows, account conditions, and provider checks affect the customer’s experience.

Neither “credit” nor “debit” alone gives a guaranteed delivery time. A successful instruction can also have later return or adjustment considerations depending on the transaction.

Ask when the quoted estimate begins and when the recipient can actually use the funds. Do not assume an available balance makes every possible return right irrelevant.

For a method comparison, read ACH versus wire transfers. For a delayed transaction, use the timing and tracking guide.

Understand returns and reversals without importing card rules

ACH returns and reversals have specific meanings and conditions under the applicable rules. They are not a universal cancellation button or identical to a card chargeback.

A return can relate to account or authorisation issues, among other reasons. A reversal has its own permitted uses and requirements. Ask the bank or provider for the actual event and reason.

Do not promise a customer a return deadline taken from a different account type or payment method. Act promptly when an unauthorised or incorrect payment is suspected and use the provider’s official process.

Before issuing a separate refund, check whether a return or dispute is already open. Our refunds and bank returns guide explains the duplicate-repayment risk.

Troubleshoot from the correct side

For an expected ACH credit, confirm the payer actually released the payment and obtain its transaction evidence. Check the receiving details and any required allocation reference.

For an unexpected debit, contact the account-holding institution or provider promptly through a known channel. Preserve the date, amount, description, and any relevant authorisation records.

For a failed debit collection, ask the originating provider for the reported reason and permitted next step. Do not repeatedly retry without understanding its rules and the customer’s authority.

Nacha explains that it does not process or inspect individual customer payments; the bank or initiating organisation is normally the appropriate starting point. Nacha: Consumer ACH FAQs.

A checklist before agreeing to an ACH arrangement

Confirm who initiates the instruction, whose account is credited or debited, the actual payer and purpose, the required authorisation, and the supported account details.

Then establish fees, timing, reference requirements, records, and what happens if the payment fails or is returned. For recurring arrangements, document changes and cancellation through the appropriate process.

If a provider cannot explain which activity “ACH support” refers to, ask for confirmation using one concrete sample payment. That is more useful than relying on the rail’s name alone.

Frequently asked questions

Can a client pay me by ACH without me offering direct debit?

Yes, where your receiving arrangement permits the client’s ACH credit. The client can initiate a supported credit without you operating a debit-collection service.

Does sharing routing and account details authorise a debit?

Possession of details is not the same as valid authorisation. Use the applicable provider process and protect the information appropriately.

Is ACH debit always automatic and recurring?

No. Debit arrangements can differ, including one-time or recurring uses. The actual authorisation and product determine the permitted activity.

Can I use ACH receiving details to pay every bill?

Do not assume so. Incoming receiving capabilities and outgoing debit permissions are separate. Confirm the intended use with the provider first.

Explore the linked sources, practical tools and related guides for more on this topic.

Explore more payment guides ↗