How eChecks Work: The Payment Journey From Authorization to Reconciliation

Three clicks on the surface. Five stages underneath.

From where the sender sits, an eCheck is barely a process at all. You fill in the details, approve it, and wait for a confirmation. Three clicks and it is someone else’s problem.

Underneath that is a sequence with five distinct stages, and each one can fail in its own particular way. Understanding how eChecks work at each stage is what lets you tell a customer why their payment has not arrived, or explain to a vendor what a returned transaction actually means, without guessing.

How eChecks work depends on which way the money is going

One thing has to be settled first, because the journey is genuinely different depending on the answer.

If you are sending, you are paying someone with a digital check. It reaches them by email, and they print it or deposit it through their own bank app much as they would a check that arrived in the post. If you are collecting, your customer is authorizing you to pull funds from their bank account, and what moves is an ACH debit.

The stages below describe both, but the obligations attached to them are not the same. Collecting brings you under ACH authorization requirements and return-rate thresholds that do not apply when you are the one paying out. Any article that walks you through a single universal eCheck process is skipping over the part that determines which rules you are actually subject to.

Stage one: the payment is created

It starts with details: the amount, the recipient, the account information the method requires, and a reference such as an invoice or account number.

This stage deserves more attention than it usually gets, for a simple reason. A payment is far easier to create than to correct once it is moving. Checking the amount, the recipient, and the invoice it belongs to takes a moment now and saves a considerably more awkward conversation later.

The reference is the part people skip, and it causes trouble at the other end. Whoever receives this payment has to work out what it is for. If the only clue is a company name and an amount, someone on their side is going to email you asking, and that is time neither of you needed to spend.

Stage two: authorization is captured

An eCheck is not just a data entry exercise. It is a payment instruction, and a payment instruction needs evidence that the payer agreed to it.

Three things make an authorization record useful rather than merely present. It should be clear about what was agreed, to what amount, and on what schedule. It should be stored somewhere retrievable by someone who was not in the room at the time. And for recurring arrangements, it has to match the actual cadence and amount of what is being charged.

That last point is where most disputes originate. An authorization for a fixed monthly figure does not cover a variable one, and a customer surprised by a charge is usually right that they never agreed to that specific version of it. Teams that treat the authorization as part of the payment record, rather than as paperwork filed elsewhere, tend to have much shorter arguments.

Stage three: the payment is submitted

With details and authorization in place, the payment goes out for processing. And this is the stage where expectations most often come unstuck, because submitting a payment and delivering funds are two different events separated by an amount of time you do not control.

Cut-off times, processing schedules, review steps, and the receiving institution’s own procedures all sit between the two. On the sending side, when the payee deposits a digital check, their bank’s deposit and review policies determine what happens next, and those vary by institution. None of this is unusual and none of it is a problem, as long as nobody has promised an arrival date.

So it is worth being careful about how you describe timing to a customer or a vendor. A range with the reasons behind it holds up. A specific date does not, and you are the one who has to explain it when the date passes.

Stage four: status is monitored

Once a payment is out, someone will ask about it. The useful question is whether your team can answer without contacting the bank.

What you want to see is where a payment stands, whether that is pending, completed, returned, or waiting on something, along with a reference tying it to the invoice it belongs to. Exceptions matter most here, because a returned payment that nobody noticed becomes a collections problem two months later. Without that visibility, teams start improvising: asking a customer to pay again, telling a vendor funds are on the way without having confirmed it, or keeping a private spreadsheet to cover what the system will not tell them.

If you are on the collecting side, returns are not only an operational nuisance. Nacha sets return-rate thresholds that originators are expected to stay under, currently 0.5% for unauthorized debit returns, 3.0% for administrative returns caused by bad account data, and 15.0% overall, each measured across a rolling sixty-day window. Crossing them draws attention from your own institution. It is a good reason to validate account details properly at the start rather than discovering the problem in aggregate.

Stage five: the transaction is reconciled

Reconciliation is where a payment becomes an accounting record rather than a thing that happened. It connects the transaction to whatever it was for: a customer invoice, a supplier bill, a recurring account.

Five things are worth retaining for each payment, and each earns its place. The authorization record, because it shows the payer agreed. The payment reference, because it connects the transaction to an invoice. The status confirmation, because it establishes what actually happened rather than what was submitted. The fee detail where one applies, because it affects the figures. And any communication about the payment, because that is what resolves a question six months on when nobody remembers the conversation.

This is the practical argument for keeping sent payments in one place regardless of their format. When digital checks, printed checks, and mailed checks all carry the same status trail and draw on the same payee list, month end becomes a lookup rather than an investigation. OnlineCheckWriter is one of the tools that handles eCheck payments this way. Split the same payees across two systems because some take digital and some want paper, and you have created reconciliation work that did not need to exist.

Where the process gets stronger

The improvements that matter are unglamorous. Consistent payment references, so both sides can identify a transaction. Deliberate permissions, so access does not quietly expand to everyone who once needed it. A review step that happens before a payment goes out rather than after. And one habit worth more than the rest: when a payee asks you to change their bank details, verify it through a channel you already trust before you use it, because requests to update payment details are a well-worn route for money to end up somewhere it was not meant to go.

None of this is about making eChecks complicated. It is about making them legible. When the payer knows what they authorized, the recipient can identify what arrived, and your team can reconcile the result without a search, the process is doing its job.

The takeaway

How eChecks work comes down to five stages: creation, authorization, submission, status monitoring, and reconciliation. Each one carries a share of whether the payment ends up clear or contested. And which direction the money moves determines which rules apply to you, so settle that before anything else.

A good payment workflow does not only move money. It leaves behind a record that somebody can still make sense of long after the payment is done.

This article is general information about business payment operations and is not financial, legal, tax, or accounting advice. Processing and delivery times are estimates and may vary based on financial institution processing schedules, payment method, and recipient bank participation. Review applicable provider terms, network rules, and internal payment controls before using any payment method.