Invoice in QuickBooks, Collect Through Stripe

Why the sync cannot see the invoice you raised

A Stripe charge can become a payment applied to a QuickBooks invoice, and that path is real. The condition on it is the part that decides your case: it applies where the charge belongs to a Stripe invoice that Acodei has already synced. The link runs from a Stripe invoice, through the record Acodei wrote for it, to the QuickBooks invoice on the other end.

An invoice you raised in QuickBooks has none of that. It was never a Stripe invoice, so no Stripe object points at it, and Acodei never wrote it. From the sync's side there is nothing connecting the incoming charge to the document sitting in your A/R, and Acodei's documentation says so directly: payments cannot be automatically applied to invoices created in QuickBooks Online.

There is a second reason worth knowing, because it explains why changing your invoicing habits does not change the outcome on its own. The choice between writing a sales receipt and writing a payment is made from the settings on your connection, not from anything about the charge. The charge does not get a vote, and neither does whatever happens to be open in QuickBooks.

What the default record does to your books

By default a successful Stripe charge becomes a sales receipt in QuickBooks, deposited to the holding account resolved for that Stripe account and currency. The Stripe fee is recorded on it as a negative line using your mapped fee product, so the receipt nets down to what actually reached your Stripe balance. Under a fee-as-expense configuration the fee posts as a separate expense instead and the receipt stays gross.

Against a QuickBooks-raised invoice, that record is correct in isolation and wrong in context. It is a well-formed sales receipt. It is also the second time that sale has been recognized, and it does nothing at all to the receivable.

The damage compounds quietly rather than loudly. Revenue is overstated by the value of every invoice paid through Stripe. A/R is overstated by the same amount, because none of those invoices ever closed. Both numbers are wrong in the same direction, which means the books still balance and nothing forces the question until someone runs an aging report and finds it full of customers who have paid.

The setting that changes which record you get

There is a different routing available. On a connection with Sales as Payment enabled, a successful charge becomes a standalone payment against the customer rather than a sales receipt. It is worth being precise about what that payment is, because the phrase suggests more than it delivers: it is a payment credited to the customer and not linked to an invoice.

That is still not automatic application, and it should not be sold as one. What it gives you is the right kind of record. Cash arrives against the customer without a second sale being recognized, and the payment is then something you can match to the open invoice in QuickBooks yourself. Acodei's documentation describes exactly this: payment receipts are created on a Stripe payment, which you manually match.

So the honest description of the workflow is that the sync stops making your revenue wrong and hands you a matching job. For a business raising a handful of invoices a month that is a good trade. For one raising several hundred, the matching is the thing to think hard about before choosing this route, because it does not get smaller as you grow.

One consequence to plan for: until a payment is matched, it is an unapplied payment, and QuickBooks reports unapplied payments in its own way on a cash basis. Our post on sales receipts versus payments covers that reporting behavior and the account it creates.

The customer name is doing more work than you think

A standalone payment is only useful if it lands on the customer whose invoice you are trying to settle, and that is a name question rather than an accounting one.

Acodei resolves the customer by checking its own stored mapping first, then querying QuickBooks for a customer whose display name matches. That match is case-insensitive but otherwise character for character. If your QuickBooks customer is "Acme Inc." and the Stripe customer is "Acme Inc", the search finds nothing and a second customer record is created. The payment then lands correctly on a customer who has no invoices, next to the customer who has the one you wanted to close.

This is worth an hour before you turn anything on. Reconciling your Stripe customer names against the QuickBooks names you already invoice under is cheap in advance and tedious afterwards, because Acodei does not update customer records once they exist and there is no manual record linking to fall back on.

Or move the invoice to the side the sync can see

The other answer is to stop raising the invoice in QuickBooks. If the invoice originates in Stripe, Invoice Sync mirrors it into QuickBooks as an open invoice in A/R, and the payment against it settles that invoice rather than sitting beside it. The link the sync needs exists because Acodei built both ends of it.

That is a real change rather than a preference, and it should be weighed as one. Your customer-facing invoice template, your numbering, your payment terms and your dunning all move to Stripe, and Acodei documents the switch to the invoice and payment workflow as a mode change best done at onboarding rather than mid-life. What Acodei syncs is the invoices and charges Stripe Billing produces. It does not run dunning, retries or proration for you, so those become Stripe configuration rather than something the sync provides.

The choice is genuinely between two workable setups, and it turns on where you want the invoice to live. Keep invoicing in QuickBooks and you keep your template and your process, and you accept a matching step on every payment. Move invoicing to Stripe and the settlement becomes automatic, and you rebuild your invoicing around Stripe to get it.