Stripe Partial Capture in QuickBooks: The Phantom Refund

A hotel authorizes 400 dollars at check-in and captures 312 at checkout. A plumber authorizes an 800 dollar estimate and captures 540 because the job turned out simpler than the quote. A rental company holds 600 and settles at 445.

Every one of those transactions puts a refund on your books that no customer requested, nobody issued, and no mistake caused. Stripe creates it automatically, and it lands in your accounting as though a sale went bad.

If your refund rate looks worse than your customer service feels, this is usually why.

Start a free trial to sync Stripe into QuickBooks Online, or read on for what the ledger is actually doing.

An authorization is not a transaction

Separating authorization from capture is one of the oldest patterns in card payments, and Stripe supports it directly. You place a hold now, and take the money later. Stripe calls this manual capture, and describes the reason plainly: "hotels often authorize a payment in full before a guest arrives, then capture the money when the guest checks out."

The important thing for your books is what a hold is not. It is not revenue. It is not a receivable. No money has moved, no service has been delivered, and the customer has not paid you. The funds are reserved on their card, sitting on their side of the fence.

So an authorization should produce nothing in QuickBooks. No sales receipt, no invoice, no journal entry. There is no transaction to record because no transaction occurred.

That sounds obvious until you notice that the customer often cannot tell the difference. Stripe is direct about this: "Card statements from some issuers and interfaces from payment methods don't always distinguish between authorizations and captured (settled) payments, which can sometimes confuse customers." A guest sees 400 dollars on their statement and calls you about it. Nothing is wrong. Nothing is bookable either.

Holds expire, and expiry is also a non-event

An authorization has a shelf life, and it varies more than most people expect. Stripe publishes the validity windows by card brand and transaction type.

For card-not-present transactions, Visa gives 5 days for a merchant-initiated transaction and 7 days for a customer-initiated one, with the exact merchant-initiated window being "4 days and 18 hours, to allow time for clearing processes." Mastercard, American Express, and Discover all allow 7 days for both.

For card-present transactions, the windows are much tighter. Visa is 5 days, and Mastercard, American Express, and Discover are 2 days each. If you take deposits on a terminal and capture at the end of a job, that 2 day window is the constraint that will bite you.

Non-card methods vary again. Klarna requires capture "by midnight of the 28th calendar day after the charge request." PayPal holds for 10 days and Stripe automatically attempts to extend it another 10, for 20 total. Cash App Pay authorizations must be captured within 7 days. Afterpay collects the first installment at authorization, refunds it if you never capture, and gives you 13 days.

Rather than working from any of these tables, read the value Stripe gives you per payment. The capture_before attribute on the charge tells you exactly when that authorization dies.

What happens if you miss it is clean, at least: "If the authorization expires before you capture the funds, the funds are released and the payment status changes to canceled." No money moved, so again there is nothing to record. Your books are unaffected. Your customer, who had funds tied up for a week for nothing, may feel otherwise.

The two balance transactions, and the refund you did not issue

Here is the mechanism that puts a phantom refund in your ledger.

When you capture less than you authorized, Stripe does not simply record a smaller charge. It records the full authorization and then reverses the difference. In Stripe's own words: if "you capture an amount less than the initial authorization, you see two balance transactions: one for the full amount of the authorization, and another reversing the uncaptured portion. (Summing the two balance transactions yields the captured portion of the charge.)"

So the 400 dollar hotel stay that settled at 312 does not appear as a 312 dollar charge. It appears as a 400 dollar charge and an 88 dollar reversal.

And that reversal is not labeled as a capture adjustment. Stripe again: "The balance transaction reversing the uncaptured portion has type=refund, just as if you had refunded a portion of a sale at some later time."

That single design decision is the source of every downstream problem in this article. A partial capture is indistinguishable from a partial refund if you are reading the type field, which is what most reporting, most exports, and a good number of sync tools read.

Note also what the amounts mean. The row that reads 400 dollars is the authorization, not the capture, and it is the row carrying the processing fee. If you are pulling the fee for a transaction, read the fee on that balance transaction directly rather than deriving it from the amount you expected to see.

Why this quietly wrecks a metric you actually watch

Refund rate is one of the few numbers a small business owner checks without being asked to. It is a proxy for product quality, for service quality, and for whether something has gone wrong this month. It is also watched by other people: card networks care about refund and dispute behavior, and so do lenders and marketplaces.

Now consider a business that authorizes high and captures low as a matter of routine.

A restaurant authorizing for the check and capturing with the tip added. A hotel authorizing for incidentals. A trades business authorizing an estimate and billing actual hours. A rental company holding a damage deposit. For these businesses, most transactions produce a reversal row, and every one of those rows reads as a refund.

The result is a refund rate that is structurally inflated, sometimes dramatically, for a reason that has nothing to do with a single unhappy customer. A shop with genuine 2 percent refunds and a habit of capturing 20 percent below authorization can show a refund rate several times its real one.

In QuickBooks the same distortion shows up as a contra-revenue figure that does not correspond to anything. If your refund lines get mapped to a Refunds product or a refunds income account, your gross sales and your refunds both climb by the uncaptured amount, and they climb together in a way that nets out to the correct revenue while making both of the underlying numbers wrong. Net income is fine. Every line above it is not.

Stripe gives you the fix, and it is one field

The solution exists and is well documented, and it is the reason reporting_category is worth learning if you have not already.

Stripe built a distinct category for exactly this case: "To allow separate handling of these objects (perhaps counting them against the initial sale amount, rather than as a separate refund) we label these with the distinct reporting category partial_capture_reversal."

So the reversal row that reads type=refund reads reporting_category=partial_capture_reversal. A real customer refund reads reporting_category=refund. The two are trivially separable, but only on the field almost nobody looks at.

This is one instance of a broader point. The type field splits things that belong together and merges things that do not, while reporting_category is built for accounting. Card charges are type=charge and other payment methods are type=payment, but both are reporting_category=charge. Refunds and payment refunds are separate types and one category. The relationship between these two fields, and what it means for the numbers you count, is covered in why your transaction counts differ between Stripe and QuickBooks, which is the right place to start if the distinction is new to you.

Practically, this means two things. When you build a refund report, filter on reporting_category and exclude partial_capture_reversal. When you look at a suspicious refund in your books, check the category before you go looking for the customer who asked for it.

What this should look like in QuickBooks

The accounting question is simpler than the Stripe mechanics: what did you actually earn?

You earned the captured amount. The authorization was a reservation, and the reversal cancelled the part of the reservation you did not use. A hotel stay that settled at 312 dollars is 312 dollars of revenue. It is not 400 dollars of revenue and an 88 dollar refund.

So the correct record is one sales receipt for 312 dollars, with the fee handled the way you handle fees everywhere else. If you are unsure how those should post, recording Stripe fees in QuickBooks covers the options.

Three reasons this matters beyond tidiness.

Sales tax. Tax follows the amount actually charged. If you booked revenue at the authorization and a refund against it, you need the tax to have followed the same path, and it frequently does not, because the reversal row carries no tax detail of its own. Booking the capture amount once avoids the problem entirely rather than correcting for it.

Customer records. A refund receipt against a customer says, permanently, that you gave that person money back. Send them a statement and it is there. For a guest whose only interaction with you was a normal stay that cost less than the hold, that is simply false.

Revenue reporting. Gross sales and refunds are both used to make decisions. Inflating them in tandem preserves the bottom line and corrupts everything above it.

The one case for recording it gross

There is a defensible exception. If your reconciliation approach is to mirror Stripe's ledger row for row, so that every balance transaction has a matching QuickBooks record, then you may want the 400 and the 88 to both exist.

If you do that, put the reversal somewhere that does not pollute the refund metric. A dedicated contra-revenue account, named something like Uncaptured Authorizations, keeps the mirror intact while keeping real refunds legible. What you should not do is route it to the same account as customer refunds and then wonder why the number is high.

One capture, and what to do when you get it wrong

This is the operational trap that costs the most time, and it deserves its own warning.

Stripe releases the remainder automatically: "A partial capture automatically releases the remaining amount." That is convenient right up to the moment you realize you captured too little.

Because you generally cannot go back. Stripe is explicit: "you can only perform one capture on an authorized payment for most payments. If you partially capture a payment, you can't perform another capture for the difference." The recommended path is to save the payment method and create a new payment later.

For your books, that means a capture entered at the wrong amount is not a correction. It is a second transaction, with its own fee, its own date, and its own sales tax treatment. Two records for one sale, arriving in different periods if the mistake is caught late.

If your business regularly needs to settle above the authorization, there are two supported routes and they behave differently.

Overcapture lets you capture more than you authorized without going back to the network. Stripe describes it as capturing "with an amount that's higher than the authorized amount," noting that "unlike incremental authorizations, overcapture doesn't result in additional authorizations with the card networks," and that after settlement "the initial pending authorization gets updated with the final captured amount."

The headroom is set by the networks and depends on what business you are in. Visa allows plus 30 percent for US eating places, fast food restaurants and caterers, plus 20 percent globally for taxis and limousines, drinking places, beauty and barber shops and health and beauty spas, the greater of plus 15 percent or 75 dollars for car rentals, and plus 15 percent for lodging, cruise lines and everything else. American Express allows plus 30 percent for restaurants and drinking places globally. Discover allows plus 20 percent for restaurants and personal care, plus 15 percent for lodging and car rentals.

Two caveats worth knowing before you plan around it. Overcapture is offered on interchange-plus pricing rather than standard pricing. And under Strong Customer Authentication you "generally need to authenticate an amount that's greater than or equal to the amount that you eventually capture," which means authorizing high and capturing low is the compliant pattern in SCA markets, not the reverse.

Extended authorization solves a different problem, which is time rather than amount. Standard online card holds last about 7 days. Extended validity "can go up to 30 days depending on the card network," with Mastercard allowing 30 days across all merchant categories and Visa allowing an effective 29 days and 18 hours. For Visa merchant categories outside hotel, lodging, vehicle rental and cruise lines, Stripe charges an additional 0.08 percent per transaction. American Express extends to 30 days for lodging and vehicle rental, but with a condition worth reading twice: "you must capture the authorized funds no later than the end of your customer's stay or rental."

A short reconciliation routine

If you suspect partial captures are distorting your numbers, this takes about fifteen minutes.

1. Export balance transactions for a month with reporting_category included, not just type.
2. Count the rows where reporting_category is partial_capture_reversal. That is your phantom refund volume.
3. Compare it to the refund figure in your QuickBooks profit and loss for the same period. A gap of roughly that size tells you the reversals are being booked as refunds.
4. Check one of them end to end. Find the original charge, confirm the authorized amount and the captured amount, and confirm that the revenue on your books equals the capture.
5. Decide your treatment once, write it down, and apply it consistently. Netting at the captured amount is the right default for most businesses.

Then do the more valuable thing: fix the reporting rather than the records. Filter partial_capture_reversal out of any refund metric you or anyone else looks at.

Before you assume your sync tool handles this

Partial captures are a genuine edge case, and edge cases are where integrations differ most. A tool reading type will see a refund. A tool reading reporting_category can see the reversal for what it is. A tool reading webhook events rather than the balance-transaction ledger may see something different again.

This is worth checking directly rather than assuming, whatever you use. Run one partial capture, then look at what appeared in QuickBooks. Is there one record at the captured amount, or two records that net to it? If there are two, where did the reversal land, and does that account feed anything you report on?

That five minute test tells you more than any feature list, and it tells you before a year of transactions have accumulated behind the wrong assumption.

Acodei syncs Stripe into QuickBooks Online, and this article is part of a longer effort to document the Stripe events that behave unintuitively once they reach an accounting system. If partial captures are on your list, Stripe fees, disputes and chargebacks and payouts are worth reading the same way.

Frequently asked questions

Why does Stripe show a refund I did not issue?

The most likely cause is a partial capture. When you capture less than you authorized, Stripe reverses the uncaptured portion, and that reversal carries type=refund. Check the reporting_category on the transaction. If it reads partial_capture_reversal, no refund was issued and no customer received money back.

Does a partial capture create a real refund in Stripe?

Not in the sense that matters to a customer. Nothing is returned to them, because nothing was taken. The reversal releases the part of the hold you did not use. It is recorded in the balance-transaction ledger in a way that resembles a refund, which is why Stripe added a separate reporting category to tell them apart.

How should a partial capture be recorded in QuickBooks?

As a single sale for the captured amount. That is what you earned, what the customer paid, and what the sales tax should follow. Recording the authorized amount as revenue and the reversal as a refund inflates both gross sales and refunds while netting to the same profit.

Can I capture the remaining amount after a partial capture?

Generally no. Stripe states that for most payments you can only perform one capture, and that after a partial capture you cannot capture the difference. The suggested approach is to save the customer's payment method and create a new payment for the remainder, which will be a separate transaction with its own fee.

How long does a Stripe authorization last?

For online card payments it is usually about 7 days, and for in-person Terminal payments about 2 days, varying by card brand and by whether the transaction is customer-initiated or merchant-initiated. Extended authorizations can reach 30 days on eligible networks and merchant categories. The reliable answer for any given payment is the capture_before field on the charge.

What happens if I never capture an authorization?

The hold expires, the funds are released back to the customer, and the payment status becomes canceled. No money moved, so there is nothing to record in QuickBooks. The customer did have funds unavailable for the duration, which is worth factoring into how long you hold.

Does the processing fee apply to the authorized or captured amount?

Read it rather than assume it. The fee sits on the charge's balance transaction, which is the row showing the full authorization amount, so the amount on that row is not the amount you captured. Pull the fee field directly instead of calculating it from the figure you see.

The point

Partial captures are not an error state. They are the normal, correct behavior of any business that reserves an amount before it knows the final one, and that includes a large share of hospitality, rentals, trades and restaurants.

The problem is only that Stripe's ledger expresses the release as something shaped like a refund, and most systems downstream believe it. One field separates the two, and one decision about how to record the capture keeps the distinction out of your books entirely.

Record what you captured. Filter what you did not.

Start a free trial and see how your Stripe activity lands in QuickBooks before the next close.