Failed ACH Payments on Stripe Invoices in QuickBooks

Your customer opens a Stripe invoice on a Monday and pays it by bank debit. The invoice flips to paid. Stripe stops sending reminders, QuickBooks shows the receivable cleared, and everyone moves on. Four business days later the debit comes back failed. The money never arrived, and your books have been wrong since Monday.

This is the part of ACH that catches teams who learned payments on cards. A card authorization is an answer: approved or declined, in about a second. An ACH debit is a request that gets answered later, and "later" is long enough for the sale to close the week, land in a report, and get reconciled by someone who had no reason to doubt it.

Here is what actually happens to a Stripe invoice paid by ACH when the debit fails, what Acodei writes and then unwinds in QuickBooks Online, and how to check that your ledger came out clean.

Start a free trial or see pricing.

Why ACH breaks the assumption cards taught you

Stripe's ACH Direct Debit settles on a delay. Standard settlement is 4 business days from payment creation, with a cutoff of 21:00 US/Eastern. Eligible US businesses can use faster settlement at 2 business days, with a 14:00 US/Eastern cutoff. Stripe exposes an expected_debit_date on the charge, and documents it plainly: "This is an estimated date of when the funds might be debited. This estimate isn't guaranteed and the actual date might vary."

During that window Stripe grants what it calls instant provisional access. The word doing the work is provisional. Stripe's own documentation says ACH Direct Debit transactions "can fail any time after the payment is initiated through payment confirmation," and lists the ordinary reasons: insufficient funds, an invalid account number, or a customer disabling debits from their bank account.

The economics are why you put up with it. ACH Direct Debit runs 0.8% capped at $5.00 per successful transaction, so a $6,400 invoice costs $5.00 to collect instead of roughly $190 on a card. For B2B invoices that is the whole argument, and it is a good one. The cost is that your accounting has to survive a payment that can be undone after it looked settled.

What your books look like during the pending window

With Invoice Sync enabled, Acodei mirrors Stripe invoices into QuickBooks Online. When a Stripe invoice is finalized, Acodei creates a QuickBooks Invoice reproducing every line item and tax line allowed by your mapping settings. When the invoice is paid, Acodei creates a Payment and applies it to the invoice it created earlier. Invoice Sync is a paid plan feature, toggled per company under Account Mapping > Premium Features.

The question a pending ACH debit raises is what to do in the gap. Acodei's documented behavior is to treat the pending payment as good: a new ACH payment in a pending state gets a Payment created against the invoice as if it had succeeded. If it does succeed, nothing changes. The record written on day one is the record you keep.

That default matters more than it sounds. The alternative, holding the payment until settlement, would leave the invoice sitting open in Accounts Receivable for up to four business days after the customer paid it. Your AR aging would show a receivable your customer would swear they settled, and every collections report in that window would be wrong in the other direction. Acodei mirrors the state Stripe is showing, which is also the state your customer sees.

Two settings shape where that payment lands. The Payment is placed according to your holding account setting, either Undeposited Funds or a non-Undeposited-Funds clearing account. And auto-application to the invoice requires QuickBooks Automatic Application to be ON. If it is off, you get a payment and an open invoice that never met each other, which is a different problem worth fixing before it compounds.

What happens when the debit fails

Acodei's documentation is candid that failed ACH payments were not handled gracefully historically. The documented behavior now is specific, and it runs in three moves.

1. The payment is deleted. The Payment Acodei created against the invoice is removed rather than offset with a second entry. The QuickBooks invoice returns to open with its full balance, and the receivable is live again. Your AR aging goes back to telling the truth, dated correctly, without a pair of canceling entries cluttering the customer's transaction list.

2. A pending sale record is written to the daily balance summary, representing the money entering the Stripe balance.

3. A reversal of that sale record is written to the daily balance summary, representing the money leaving the Stripe balance, dated the day of the failure.

The net effect of moves 2 and 3 on your ledger is zero, and that is what makes them useful rather than redundant. The money did enter your Stripe balance provisionally and then did leave it. Your daily balance summary for the failure date reflects both movements instead of showing nothing at all, which is what keeps that day's summary tying to Stripe's own record of the same round trip.

A worked example

You invoice a customer $6,400 through Stripe on August 3 and they pay by ACH the same day.

August 3. Stripe finalizes the invoice and marks it paid on the provisional debit. Acodei creates the QuickBooks Invoice for $6,400 and a Payment for $6,400 applied against it, deposited to your holding account. AR for this customer: zero. Everything looks finished.

August 7. The debit fails for insufficient funds. Stripe emits the failure. Acodei deletes the $6,400 Payment. The invoice reopens at $6,400 and lands back in AR, aged from its original date. The daily balance summary for August 7 carries a $6,400 pending sale line and a $6,400 reversal of that line.

Where the numbers end up. AR: $6,400 open, correctly. Holding account: unchanged on net, because the payment that debited it is gone. Revenue: recognized once, on the invoice, which is where it belonged the whole time. Daily balance summary for August 7: net zero across the two lines, with both movements visible.

The single most useful consequence is the one that is easy to miss. Your Stripe clearing account does not drift. Out-of-band and half-reversed payments are the classic way a Stripe clearing account stops returning to zero, and a failed ACH debit is exactly the shape of event that creates a permanent variance if it gets handled with a manual journal entry instead.

The one case this does not cover: a late return

There is a second failure mode, and it arrives wearing different clothes.

Stripe documents it directly: "In rare situations, Stripe might receive an ACH failure from the bank after a PaymentIntent has transitioned to succeeded. If this happens, Stripe creates a dispute with a reason of insufficient_funds, incorrect_account_details, or bank_cannot_process." Stripe also charges a failure fee in this situation.

Read that carefully, because it changes which part of your books absorbs the hit. This is not a failed payment. Stripe already settled it, so it comes back as a dispute, and it flows through the dispute path rather than the payment path. In Acodei, disputes and other uncommon balance transactions are mapped once in Balance Transaction Mapping, and from there Acodei processes them in the daily balance summary or upon payout, depending on your settings. They are never written as per-dispute journal entries or itemized expense lines. The accounting side of Stripe disputes is worth reading in full if ACH is a meaningful share of your volume.

Two more facts worth knowing before you build a process around this. Customers have up to 60 calendar days from the date of purchase to file an ACH Direct Debit dispute, which is a much longer tail than most teams plan for. And unlike card disputes, all ACH Direct Debit disputes are final, with no process for appeal.

What to check in QuickBooks after a failure

Run this the first few times until you trust it, then spot check monthly.

1. The invoice is open again at its full original amount, aged from the original invoice date rather than the failure date.
2. No orphan payment survives. Open the customer's transaction list. You should see the invoice, and no payment for the failed attempt.
3. The daily balance summary for the failure date carries both lines, the pending sale and its reversal, netting to zero.
4. Your holding account is unchanged on net for that transaction. If Undeposited Funds or your clearing account moved and stayed moved, something was recorded by hand.
5. Nothing was fixed manually. This is the one that bites. If a bookkeeper spotted the failure and keyed a reversing entry before the sync caught up, you now have the reversal twice.

That last point is worth stating as a rule: when a synced record looks wrong, resync it from the Data Feed rather than editing it in QuickBooks. Acodei's own best-practice guidance says exactly this, and a resync deletes and re-adds the records from source data, which quietly discards whatever a manual edit had done. A hand-keyed correction is not preserved by a resync; it is competing with one.

Acodei also validates invoice payments as it records them, checking that the correct payment amount is applied to the QuickBooks invoice and that the payment is linked to the correct invoice. Those checks run when recording the payment, so a failure that unwinds cleanly should leave nothing for them to catch later.

If the customer never pays at all

A failed debit is not automatically a bad debt. Most fail once, the customer funds the account, and the retry clears. But if the invoice ends up genuinely uncollectible, Stripe's invoice.marked_uncollectible event is handled like a void on the Acodei side, and if that invoice is later paid after all, Acodei reopens it, clears the void transactions, and processes the new payment. You do not need to rebuild the invoice by hand to collect on it late.

For the accounting itself, writing off an uncollectible receivable stays a deliberate decision you make in QuickBooks against a bad debt expense account, on your own judgment about the customer and the period.

Where this shows up at month end

Three places, in the order you will hit them.

AR aging. A reopened invoice is aged from its original date, not from the failure. An invoice issued August 3 and failed August 7 shows as 4 days old on August 7, not new. That is correct, and it means a wave of ACH failures makes your aging deteriorate suddenly rather than gradually. Worth knowing before you go looking for a cause that is not there.

The holding account. It should tie out exactly as if the failed payment never happened. If your clearing account is off by the amount of a failed debit, look for a manual entry first.

Payout reconciliation. Failed debits never reach a payout, because the money left the Stripe balance before the payout was assembled. If you are matching deposits to payouts line by line, a failure is not a discrepancy, it is an absence. The full method is in the Stripe payout reconciliation guide.

One related scenario trips people at the same moment: an invoice a customer paid by check while the Stripe invoice was still open. That one has its own trap, covered in marking a Stripe invoice paid outside Stripe.

FAQ

How long does a Stripe ACH payment take to settle?

Standard settlement is 4 business days from payment creation, with a 21:00 US/Eastern cutoff. Eligible US businesses can enable faster settlement at 2 business days, with a 14:00 US/Eastern cutoff. Stripe provides an expected debit date on the charge, but documents that the estimate is not guaranteed and the actual date can vary.

Does a failed ACH payment leave a payment record in QuickBooks?

No. Acodei deletes the Payment it created against the invoice when the ACH debit fails, so the invoice returns to open at its full balance. What remains is a pending sale record on the daily balance summary and a reversal of that record dated the day of the failure, which net to zero.

Does Acodei wait for the ACH debit to settle before recording the payment in QuickBooks?

No. A new ACH payment in a pending state gets a Payment created against the invoice as if it had succeeded. If the debit settles, that record stands unchanged. If it fails, Acodei deletes the payment and posts the two offsetting daily balance summary lines. The practical effect is that your Accounts Receivable matches what Stripe and your customer both show during the settlement window.

What is the difference between a failed ACH payment and an ACH late return?

A failure happens before the payment reaches a succeeded state, and it unwinds through the payment path. A late return arrives after Stripe has already settled the payment, and Stripe raises it as a dispute with a reason of insufficient funds, incorrect account details, or bank cannot process. Disputes flow through Balance Transaction Mapping instead, and Stripe charges a failure fee.

How long do customers have to dispute an ACH payment?

Up to 60 calendar days from the date of purchase. Unlike card disputes, ACH Direct Debit disputes are final and there is no appeal process, so evidence quality on the front end matters more than a response strategy after the fact.

Should I fix a failed ACH payment manually in QuickBooks?

No. Resync from the Data Feed instead of editing the records in QuickBooks. A resync rebuilds the invoice and payment from source data, so a manual correction made in the meantime is discarded rather than preserved. A hand-keyed reversal layered on top of an automatic unwind is also how this scenario ends up double counted.

The short version

ACH gives you a $5.00 cap instead of a percentage that scales with your invoice size, and charges you for it in certainty. A debit that fails four business days after your books recorded it is normal, not an incident. What matters is that the unwind is complete: the payment removed, the invoice reopened at full value, and both sides of the provisional money movement visible on the failure date so your daily summary still ties to Stripe.

If you are collecting B2B invoices through Stripe and reconciling them in QuickBooks Online by hand, this is the exact scenario where hand reconciliation quietly fails. Start a free trial and see what a clean unwind looks like on your own data.