Stripe Received Debit

The field that tells you what pulled the money

Because a received debit can come from three unrelated places, the useful work is identifying which one you are looking at, and the object carries the answer in two places rather than one.

The first is the initiating payment method details, which Stripe describes as a polymorphic type matching the originating money movement’s source. It resolves to a US bank account when an external account holder pulled by ACH debit, in which case Stripe also records the bank name, the routing number and the last four digits of the account. It resolves to an Issuing card when the movement was card spend. It resolves to a financial account when the source was another financial account. And it resolves to a balance, with the value payments, which Stripe notes is only set when the source is a payout.

The second is the linked flows object, and it is the more revealing of the two because it points at the thing that caused the debit rather than at the instrument. Stripe documents six pointers on it. A debit reversal is set when this received debit has itself been reversed. An inbound transfer is set when the received debit is associated with an inbound transfer’s return of funds. An issuing authorization is set when the debit was created by an Issuing authorization, and an issuing transaction is set when the same debit is also viewable as an Issuing dispute. A payout is set when a payout caused it, and a top-up is set when a top-up did.

Read those six together and the shape of the object becomes clear. Only two of them are spending in any ordinary sense. The rest are your own money moving, or money coming back. A received debit is a category of event, not a category of expense, and the linked flow is what separates the two.

Two statuses, and one of them leaves nothing behind

Most Stripe money-movement objects have a lifecycle. This one barely has one.

Stripe documents exactly two statuses for a received debit, succeeded and failed, and says they are created with one or the other already set. There is no processing state and nothing to wait on, because by the time the object exists the decision has been made. It was approved, or it was declined.

The consequence is worth stating plainly: Stripe records that when a received debit fails, it was declined and no transaction was created. Nothing moved and nothing posted. If you are looking for a QuickBooks record for a card charge that Stripe shows as failed, there was never anything to sync.

When one does fail, Stripe attaches a reason, and the documented codes are narrower and more diagnostic than most failure enums. Insufficient funds means the financial account balance could not cover it. Account closed and account frozen both mean funds cannot be pulled from the account in its current state, which is an account-level problem rather than a transaction-level one. There is a generic other. And there is one that surprises people: international transaction, which Stripe documents as international transactions being unable to pull funds from the financial account at all.

That last one is a rule rather than a failure. A declined card abroad is not a balance problem and retrying it will not help.

An expense that can be pulled back, but not forever

A received debit that succeeded is not necessarily final, and the window in which it can be undone is recorded on the object rather than left to the calendar.

Stripe attaches reversal details carrying a deadline, which it defines as the time before which a received debit can be reversed. Reversing one produces a separate debit reversal object, and the original received debit then links to it. So a reversal is an additional movement rather than an erasure, which is the same pattern Stripe uses for returned inbound transfers.

When a received debit cannot be reversed, Stripe says why with a restricted reason. It may be already reversed. It may be deadline passed, which Stripe explains directly: ACH received debits are only reversible for some time after they are created. It may be network restricted, where network constraints prevent Stripe from allowing a reversal. It may be source flow restricted, meaning the flow that caused the debit is not itself reversible. Or it may fall to a generic other.

For a close, the deadline is the part that matters. An expense sitting in a period you are about to lock may still be reversible on the Stripe side for a short window after that period closes, and the reversal will land as a movement of its own on a later date. Checking the reversal deadline on anything large near a cutoff is cheaper than reopening a period.

One documented treatment, and a boundary worth respecting

Acodei’s documentation describes a received debit as money taken out of your Stripe financial account, usually because of a card payment made using a Stripe-issued card, and records it as a Purchase or Expense in QuickBooks. It is paid from your Stripe financial account holding account, and its category comes from the expense account you selected on the Account Mapping page.

That mapping lives in its own section, separate from the one for external bank accounts. The external bank account section covers accounts your business owns that money moves to and from, which is what inbound and outbound transfers use. The expense section covers spending made directly from the financial account balance, which is where outbound payments and card spend land. Two sections, because they answer two different questions.

Here is the boundary. Acodei’s documentation covers the card-spend case and does not describe the other origins Stripe’s object can carry. A received debit created by a top-up, by a payout, or by the return of an inbound transfer is not money you spent, and booking one as an operating expense would overstate expenses and miss a balance sheet movement. We are not going to tell you those cases are handled a particular way when the documentation does not say so. If a received debit appears on your financial account and its linked flow points at a top-up, a payout or an inbound transfer, check how it posted rather than assuming it followed the card-spend treatment.

The card case itself is well defined, and it is the one that will account for nearly all of these on a normal account.