Stripe Charge in QuickBooks: Sales Receipt vs Payment

You go looking for the sales receipt behind a $340 Stripe charge and it is not there. What you find instead is a payment applied to an invoice. Or worse, a payment sitting against the customer applied to nothing at all. The charge is real, the money arrived, and QuickBooks has recorded it in a form you were not expecting.

Nothing is broken. One kind of Stripe event, a successful charge, can land in QuickBooks as any of three different record types. Which one you get is decided before the charge ever happens, by a setting on the account rather than by anything about the charge itself.

That last part is the piece almost everyone has backwards. The reasonable assumption is that the charge tells the sync what to create: charge attached to an invoice, so obviously it becomes an invoice payment. The actual order of operations runs the other way.

Start a free trial of Acodei if you want this handled rather than diagnosed. The rest of this post is the mechanism, because the three records do genuinely different things to your books and picking between them is not a formatting choice.

The three records are not variants of each other

Start with the ledger, not the form. Each of these records has a different effect, and the differences are the reason the routing matters.

A sales receipt recognizes income and receives the cash in a single document. Intuit's own framing is that a sales receipt "records goods or services paid for immediately at the time of purchase," as distinct from an invoice, which "informs your customers of what they owe you." The difference between invoices, sales receipts, bills, and statements comes down to payment timing. Nothing passes through accounts receivable, because nothing was ever owed.

A payment receipt applied to an invoice does something quite different. It creates no new income at all. The revenue was already recognized when the invoice was booked. What the payment does is reduce accounts receivable and bring the cash in. If you count this record as revenue, you have counted the sale twice.

A standalone payment against the customer is the third case, and the one that causes the most confusion. Cash arrives and is credited to the customer, but it is not applied to any particular invoice. In QuickBooks that is a real state with real reporting consequences: on a cash basis, unapplied payments surface in an account called Unapplied Cash Payment Income. Intuit is explicit that this account is created by QuickBooks itself, cannot be deleted or modified, and appears when payments are entered "without matching them to sales forms."

Now the stakes are concrete. If a charge that paid an invoice gets booked as a sales receipt, you have recognized the same revenue twice and the invoice is still sitting open in receivables. If a payment never gets applied, your accrual numbers can look right while your cash-basis profit and loss grows a line item most owners have never heard of. These are not cosmetic differences between three ways of saying "money came in."

What actually decides which record you get

Here is the part worth internalizing.

By default, a charge.succeeded or charge.captured event becomes a sales receipt. That is the ordinary path and it covers most accounts.

On a connection with Sales as Payment enabled, or where a custom payment rule applies to that account, the same event instead becomes a standalone payment against the customer, not linked to an invoice.

And where the charge belongs to a Stripe invoice that has already been synced, it becomes a payment receipt applied to that QuickBooks invoice.

The load-bearing detail is which of those choices happens where. The decision between the sales-receipt job and the payment job is made by the dispatcher from account settings, not from whether the charge has an invoice attached. The invoice question is resolved later, inside the sales-receipt job, which branches internally once it knows whether the transaction is an invoice payment.

So there are two decisions, made at different times, by different things:

1. Account setting, decided up front: sales receipt path, or standalone payment path.
2. Invoice linkage, resolved during the job: within the sales receipt path, plain sales receipt or payment receipt against the invoice.

This explains a support conversation that otherwise makes no sense. Two businesses both take a Stripe payment against a Stripe invoice. One ends up with the payment applied to the QuickBooks invoice, the other with a standalone payment credited to the customer and the invoice still open. Same Stripe object, same event, different account setting. The charge never had a vote.

It also explains why toggling settings while staring at a single transaction rarely teaches you anything. The setting governs the path for everything on that connection, and the record you are looking at was routed under whatever the setting was at the time.

Why the invoice link is the genuinely hard part

You would think determining whether a charge belongs to an invoice would be trivial. It is not, and the reason is visible in Stripe's own data model.

Look at the Charge object. It carries amount, amount_captured, captured, paid, status, payment_intent, customer, balance_transaction. What it does not carry is an invoice field. The charge does not announce which invoice it paid.

The relationship lives on the other side. The Invoice object exposes a payments list, described as "Payments for this invoice," pointing at invoice payment records for the detail. The invoice knows about its payments. The charge does not know about its invoice.

Timing compounds it. Stripe builds a deliberate delay into invoice processing. The attempted field notes that "an invoice is not attempted until 1 hour after the invoice.created webhook," and webhooks_delivered_at describes invoices being "automatically paid or sent 1 hour after webhooks are delivered." Invoice creation and invoice payment are separated by design, sometimes by a lot, and the events reach you as separate deliveries with their own retry behavior.

Put those together and the ordering problem is unavoidable. A charge event can arrive while the system's knowledge of the corresponding invoice is incomplete. Not because anything failed, but because the two facts genuinely become available at different moments.

The mid-job promotion, and the race it exists for

This is where the design gets interesting, and it is the part nobody documents.

Whether a transaction is treated as an invoice payment is normally settled at webhook time. But the sales receipt job does not simply trust that early determination and proceed. A charge can be promoted mid-job to the invoice-payment path, under either of two conditions: a custom handler claims the account, or Invoice Sync is on and the linked invoice.created row has since been written to QuickBooks.

That second condition is the one to sit with. It covers the case where Stripe back-fills the charge-to-invoice link after the original webhook arrived. The charge showed up looking like an ordinary sale. By the time the job actually ran, the invoice existed in QuickBooks and the link was known. Rather than writing the record it had originally planned, the job re-checks and switches.

The re-check exists because the race is real. Without it, the same charge could reasonably become either record depending on nothing more than which event won by a few seconds. That would make your books a function of network timing, which is an unacceptable property for an accounting system.

It also means the honest answer to "why did this charge book differently than that one" sometimes involves sequence rather than configuration. Two charges, same account, same settings, different outcomes, because one arrived before its invoice was written to QuickBooks and one arrived after. The promotion logic is what keeps that from producing a wrong record, but it does not make the two paths identical.

Where the Stripe fee lands in each case

The fee follows the record type, which surprises people who expect one fee treatment per account.

On a sales receipt, the fee is recorded by default as a negative line using the mapped Stripe fee product. The receipt nets down to what actually entered your Stripe balance, which is what makes the deposit tie out. Under fee-as-expense configurations, the fee instead posts as a separate purchase or expense and the receipt stays gross.

On the invoice-payment path, the fee posts as a separate expense. It cannot net inside the payment, because the payment's amount is determined by the invoice it is settling. An invoice for $500 gets paid $500 even though $485.50 reached your balance. The difference has to live somewhere else.

That is worth flagging if you are reconciling by eye, because it changes what a "matching" record looks like. On the sales receipt path the record roughly matches the deposit. On the invoice path it matches the invoice, and the fee is somewhere else entirely. If fee handling is your main reconciliation headache, the full walkthrough of reconciling Stripe fees in QuickBooks covers the account structure in more depth.

Regardless of which record gets written, the deposit target is the resolved holding account for that Stripe account and currency, rather than your real bank account. If the holding-account concept is new to you, the undeposited funds entry covers why an intermediate account is the correct place for money that Stripe has but your bank does not yet.

Two cases where none of this applies

Daily summary accounts do not get a per-charge record at all. Their charges are aggregated into one receipt per day, so there is no individual sales receipt or payment to go looking for. If you are hunting a specific charge and finding nothing, check which mode the account is in before assuming a sync failure. The tradeoffs between the two modes are covered in daily summary versus real-time syncing.

Account-specific overrides exist. Eleven job subclasses live alongside the standard ones, plus Partner and Thinkific sales and refund variants, and they override these defaults per account. If your account is on one, the general rules above are the starting point rather than the final answer.

How to predict what you will get

A short version you can apply without reading code:

• Is the account on daily summary? Then there is no per-charge record. Stop here.
• Is Sales as Payment enabled on the connection? Then charges become standalone payments credited to the customer, and applying them to invoices is a manual step in QuickBooks.
• Otherwise, did the charge pay a Stripe invoice that was already synced? Then you get a payment receipt applied to that QuickBooks invoice, with the fee as a separate expense.
• Otherwise, you get a sales receipt with the fee as a negative line, deposited to the holding account.

If what you are seeing does not match, the two likely explanations are an account-specific override or a timing case where the invoice link resolved later than the charge. Both are worth checking before changing any settings.

Frequently asked questions

Why did my Stripe charge post as a payment instead of a sales receipt?

Because the connection has Sales as Payment enabled, or a custom payment rule applies to the account. That routing is chosen from account settings by the dispatcher, not from anything about the charge. A charge with no invoice attached will still become a payment on such a connection.

Why is my Stripe invoice still showing as open in QuickBooks after the customer paid?

One cause worth checking first is that the payment was recorded as a standalone payment against the customer rather than applied to the invoice. The cash is in the file, but nothing was applied to the receivable. On a cash-basis profit and loss those unapplied amounts show up as Unapplied Cash Payment Income, which is QuickBooks' own signal that a payment is not matched to a sales form.

Can the same charge become different records at different times?

The record type can be settled later than you would expect. A charge can be promoted to the invoice-payment path during the job if the linked invoice has since been written to QuickBooks, which covers Stripe back-filling the charge-to-invoice link after the original webhook. The re-check exists precisely so that a timing difference does not produce the wrong record.

Why does the Stripe fee show differently on invoice payments?

Because a payment applied to an invoice has to equal the invoice amount. There is no room to net the fee inside the record, so it posts as a separate expense. On a sales receipt the fee can be a negative line, which nets the record down to what actually reached your Stripe balance.

Does the charge having an invoice decide which QuickBooks record I get?

Only partly, and not at the level people assume. The account setting decides between the sales receipt path and the payment path. The invoice question is resolved inside the sales receipt path, deciding between a plain sales receipt and a payment receipt against the invoice. A charge attached to an invoice on a Sales as Payment connection still becomes a standalone payment.

Getting the routing right

The reason this matters is not tidiness. Each of the three records makes a different claim about your business: revenue earned and collected, a receivable settled, or cash held against nothing in particular. Pick the wrong one and your revenue is overstated, your receivables are wrong, or your cash-basis reporting sprouts an account you did not create.

Acodei routes each successful Stripe charge to one of those records based on how the account is configured, re-checks the invoice link during the job rather than trusting the first look, and deposits every record to the holding account resolved for that Stripe account and currency. If you would rather have this decided consistently than investigate it one transaction at a time, start a free trial or see how the pricing works.