Stripe Outbound Transfer

The mapping it needs is a bank account, not an expense category

This is the practical difference between the two outbound objects, and it shows up before any money moves, in setup.

Acodei’s Account Mapping page has a section for the external bank accounts connected to your Stripe financial account. Those accounts are owned by the business, and the documentation describes them as the accounts used to send or receive money from the financial account balance. An outbound transfer is what uses that mapping. You are telling Acodei which QuickBooks bank account is the other end of the movement.

The expense mapping is a different section entirely. That one exists to say which QuickBooks account tracks expenses made directly from the financial account, and it is what outbound payments and card spend draw on.

So the two objects consume two different parts of your configuration. If outbound transfers are landing somewhere you did not expect, the bank account mapping is where to look, and changing your expense category will do nothing at all.

One more piece of setup sits above both. A financial account can hold several currencies, and Acodei’s documented setup gives each currency its own QuickBooks holding account. The transfer is drawn from whichever holding account matches its currency.

Inbound and outbound are the pair that matters

The word outbound invites you to compare an outbound transfer with an outbound payment. For bookkeeping the more useful pairing is the other one.

Acodei’s documentation puts it plainly. An inbound transfer is money moved into the Stripe financial account from the business’s bank account. An outbound transfer is money moved out of the financial account to the business’s bank account. Same two accounts, opposite directions, and both produce a QuickBooks Transfer.

That symmetry is what makes them easy to reason about at month end. Over any period, the inbound transfers and outbound transfers between a given pair of accounts net against each other, and neither one touches your profit and loss. They move the balance sheet around and nothing else.

An outbound payment breaks that symmetry, because it has no inbound counterpart and it does hit your profit and loss. If you are reviewing financial account activity and trying to work out what actually cost you money, the transfers are the rows you can safely set aside.

Money in a processing transfer is still in your balance

Stripe documents five statuses for an outbound transfer: processing, posted, failed, returned and canceled. The definitions carry a detail that matters for a period cutoff.

A transfer starts in processing. In that state Stripe holds the funds with a pending transaction, but they are still part of your current balance. The money has not left yet. It reaches posted once the transfer is confirmed and the funds have actually left the account.

The other three are all reversals of a kind. A canceled transfer was stopped by a user before posting, and Stripe returns the funds by voiding the pending transaction. A failed transfer never confirmed, and the funds are returned the same way. A returned transfer is the awkward one: it posted, the money left, and then it failed to arrive at the destination, so the funds come back with a second posted transaction attached to the same flow.

That last case is the one worth designing around. A returned transfer produces two posted movements rather than an erased one, so a bank account reconciliation that expects a single clean row will not find it.

The object also carries a cancelable flag telling you whether it can still be stopped, and separate timestamps for each of the canceled, failed, posted and returned transitions. There is an expected arrival date too, but Stripe does not set it when the transfer is in a failed, canceled or returned state, so its absence is itself a signal.

Local or wire, and why the choice reaches your books

An outbound transfer carries a delivery option for the bank account, and Stripe documents three values: automatic, which lets Stripe pick, local, meaning the group of local bank-transfer networks in the bank account’s country, and wire, meaning the wire transfer networks in that country.

This is not a technicality. Local rails and wire rails differ in how fast they settle and in what they cost, and Stripe returns errors when an amount is too large for the delivery option selected, or when no suitable option exists for a large amount. A finance team that sweeps a large balance at month end and a team that moves small amounts weekly are not making the same choice here.

Stripe charges fees on these movements, and Acodei’s documentation is specific about where they land: fees on transfers and outbound payments are recorded separately, as part of a daily balance summary built for financial accounts. That is a different summary from the one used for the ordinary Stripe payments balance. The fee is not on the Transfer record, by design, so a Transfer whose amount looks slightly wrong is usually a Transfer whose fee you have not found yet.

Two smaller fields are worth knowing when something goes missing. Stripe generates a receipt URL, which stays active for 60 days from the creation date and then expires to null, so it is worth capturing rather than relying on later. And a trace ID, which is what a receiving bank calls a reference number. Its status starts as pending and becomes supported or unsupported depending on the bank, and Stripe notes it can remain pending even after the transfer has posted.

When a transfer does not arrive

Stripe attaches a reason to both of the unhappy outcomes, and the two lists are different in a way that tells you who has to fix it.

A failure, meaning the transfer never confirmed, comes with reasons like the payout method being declined, not existing, having expired, being unsupported, or a usage frequency limit having been exceeded.

A return, meaning it left and came back, comes with a longer and more human list: the destination account was closed or restricted, the account number was invalid, the currency was not supported by that account, the account holder’s name, address or details were incorrect, the customer canceled it, or the transfer was recalled.

The practical read is that failure reasons point at the payout method configured in Stripe, while return reasons mostly point at the real bank account on the other end. Both lists end with an unknown failure catch-all.

In QuickBooks terms, the reason a returned transfer deserves attention is that you have already recorded money leaving the financial account. If it comes back, your holding account and your bank account will both be wrong until the return is recorded too.