Stripe Tips and Gratuities in QuickBooks Online

A card reader at a coffee counter takes $58.40. Ten dollars of that is a tip the customer added on the screen, and by the time it reaches your books it is $58.40 of sales. One number, one deposit, one line on a payout.

If the tip is yours, that is the correct answer and there is nothing to fix. If the tip is owed to the person who made the drink, you have just recorded someone else's money as your income, and you will keep doing it every day until something forces the question.

This is not a sync problem. It is a classification problem that a sync will faithfully carry out either way, and the fix starts one step earlier than most people look.

Start a free trial and see how your Stripe charges break down in QuickBooks.

Whether the tip is revenue at all

Start here, because every other decision depends on the answer and no amount of Stripe configuration will produce it.

A tip is your revenue when it belongs to the business. A service charge you set and keep, a delivery gratuity that funds the delivery operation, a tip at an owner-operated business with no other staff: these are sales, they belong in income, and the default treatment is already right.

A tip is a liability when it is owed to someone else. You collected it on their behalf, you are holding it, and you will pay it out. It is not income, it does not belong in your P&L, and recording it as revenue overstates two things at once. Your income is too high by the amount of the tips, and every ratio computed from that income is distorted with it.

The distinguishing question is short: when this money leaves your bank account, who receives it? If the answer is your staff, the tip was never yours, and the moment you collected it you took on an obligation rather than earning a sale.

Two practical notes before the mechanics. The determination depends on your jurisdiction, your employment arrangements, and in some places on whether the tip is voluntary or a mandatory service charge, and those rules genuinely differ. A mandatory service charge is treated as business revenue in more jurisdictions than a voluntary tip is. This post covers where the money is and how to record what you have decided; the decision itself is worth ten minutes with your accountant, once, because it does not change often and getting it right shapes every period afterward.

Where the tip actually lives in Stripe

The honest answer is that it depends on how the tip was collected, and the three methods produce genuinely different data. This is the part worth knowing precisely, because it determines whether you can automate anything at all.

Stripe documents two ways to collect a voluntary tip through Terminal, and one rule for the involuntary case. For mandatory tips, Stripe is explicit: "you must include the tip amount in the original PaymentIntent amount. You can't use on-receipt or on-reader tipping." That case is the simplest and the least recoverable. The tip is part of the amount from the beginning, nothing marks it, and no field anywhere separates it later. If you set a mandatory service charge and need it split out, the split has to happen in your own system before the charge is created.

The two voluntary methods are where the interesting differences are.

On-reader tipping, where the tip is a named field

With on-reader tipping the card reader suggests tip amounts to the customer before the payment is taken. Stripe describes the resulting data precisely: "When you process the payment, the reader adds the selected tip. If the payment is successful, the amount in the PaymentIntent and Charge updates to include the tip amount."

The tip is then exposed in a dedicated place. On the PaymentIntent, amount_details.tip.amount is documented as the "Portion of the amount that corresponds to a tip." The parent amount_details object is described as providing "industry-specific information about the amount", which is a fair description of what a tip is: a component of the total that only some businesses have.

There is a detail in the field's behavior that is more useful than it first appears. Stripe documents three possible return values, and they are not interchangeable:

Scenario	amount_details.tip.amount
On-reader tipping is disabled	null
On-reader tipping is enabled, no tip selected	0
On-reader tipping is enabled, tip amount selected	The amount selected

A null and a zero mean different things. Null means the customer was never asked. Zero means the customer was asked and declined. If you ever want to know your tip rate, that distinction is the denominator, and it exists only in this field.

One more piece of timing worth holding onto, because it catches people reading the object at the wrong moment. Stripe documents that before confirmation the tip returns in an amount_tip field and not in amount; after confirmation, amount_tip is set to zero, amount includes the tip, and the tip moves into amount_details. Reading amount_tip on a completed payment returns zero, which looks exactly like a declined tip and is not one.

On-receipt tipping, where the tip is a subtraction

On-receipt tipping is the restaurant pattern: the card is authorized for the check, the customer writes a tip on the paper receipt, and the final capture is larger than the authorization. Stripe implements this with overcapture. "In the US, after you confirm a PaymentIntent, you can collect a tip by capturing more than the authorized amount. This is known as overcapture."

Here there is no tip field at all. Stripe says so directly: with on-receipt tipping, tips "aren't directly represented but can be derived from the Charge object." The derivation is a subtraction, and Stripe spells out both operands. You "derive the tip by subtracting amount_authorized from amount", where amount_authorized "is the original authorized amount exclusive of the tip" and amount_captured and amount "are the same and both are inclusive of the tip."

So the tip is recoverable, but only as a difference between two numbers, and only for card-present payments, because amount_authorized lives inside the card-present payment method details rather than at the top of the charge.

The constraints on this method are worth knowing before you plan around it, because they are narrower than most people expect:

• It is US-only. Stripe documents on-receipt tipping as "available for United States businesses with eligible merchant category codes (MCCs), for payments using Visa, Mastercard, Discover, and American Express card brands."
• The eligible categories are enumerated, and they are the ones you would guess: taxicabs and limousines, eating places and restaurants, drinking places, fast food restaurants, and beauty and barber shops.
• It requires manual capture. On-reader tipping works with both automatic and manual capture, because the total is known before authorization. On-receipt cannot, because the tip does not exist yet at authorization time.
• There is a ceiling. Stripe documents that you "can overcapture up to 50% of the PaymentIntent's authorized amount, or 50 USD, whichever is greater."

That last one is a real operational limit rather than a technicality. A $40 check can be captured up to $90. A $200 check can be captured up to $300. Tips above the ceiling need incremental authorization or a second payment, and the relationship between an authorization and a capture that differs from it is worth understanding on its own, which partial captures in QuickBooks covers.

Eligibility is also checkable per payment rather than assumed: Stripe directs you to expand the PaymentIntent's latest_charge and inspect overcapture_supported.

The Charge object never carries a tip

This is the single fact that explains the accounting behavior downstream, and it is true of both methods.

For on-reader tipping, Stripe states that tips "aren't directly represented in the Charge object", and that after capture, amount, amount_authorized and amount_captured "all show the same value inclusive of the tip." For on-receipt tipping the tip is derivable from the charge, but by arithmetic rather than from a field.

The Charge object has no tip field in either case. It has one amount, and the tip is inside it.

That has a consequence that runs all the way to your bank. Because the tip is part of the charge amount, it is part of the same balance transaction, settles on the same schedule, and arrives in the same payout line as the sale it rode in on. There is no separate tip settlement to reconcile against, and no point in the money movement where Stripe hands the tip over separately.

What happens by default when a tipped charge syncs

Now the two halves meet, and the outcome follows from the structure rather than from any decision anyone made about tips.

Acodei's documented behavior for a real-time account is that a successful Stripe charge becomes an itemized QuickBooks sales receipt deposited into the holding account. On the line items, the documentation is specific: they "come from Product Mapping (or Multiple Product Mapping when enabled)", where "each Stripe line resolves to a mapped QBO product", and "unmapped lines use the default product."

Read that against what Stripe actually sends. The tip is not a Stripe line. It is a portion of the amount, or a difference between two amounts, depending on the method. There is no tip line for a mapping rule to resolve, because there is no line.

So the tip joins the amount of whatever the charge does carry, and lands wherever that resolves. On a coffee-shop charge mapped to a single default product, the $10 tip becomes $10 of that product's income, indistinguishable from the drink. Nobody chose that. It is the arithmetic of an amount that includes a tip meeting a mapping engine that reads lines.

The rest of the record is documented and worth knowing, because two parts of it help later. The deposit account is "always the resolved holding account for the transaction's Stripe account and currency", which is the holding account pattern the whole reconciliation rests on. And the audit trail is real: Acodei documents that the PrivateNote on the record captures the original charge amount and the Stripe fee. That note is the thing that lets you check a specific record against Stripe later without opening two tabs.

Acodei documents a break-out for shipping and for coupons, and not for tips

This is worth stating plainly rather than leaving as an inference, and it is a statement about the documentation rather than about the code.

Acodei's admin documentation lists toggles that break specific non-sale amounts onto their own QuickBooks lines. Enable Shipping Cost Tracking "breaks out Stripe shipping (amount_shipping) as its own line" and needs a designated Shipping product. Enable Coupon Tracking "posts coupons/discounts as separate line item" and requires a Discounts default product.

There is no equivalent documented for tips. No toggle in the advanced settings table addresses them, and no page in the product documentation covers tips or gratuities at all.

That is a documented absence, not a documented "no", and the distinction matters for what you should do about it. It means this post cannot tell you that Acodei separates tips, and cannot tell you that it never will. It means the honest planning assumption today is that the tip follows the line that carries it, and that if you need it separated, the separation is yours to make in QuickBooks rather than something to look for in a setting.

The general shape of this problem, which amounts a mapping rule can reach and which need a toggle instead, is worked through in Stripe amounts product mapping cannot reach. Tips are a cleaner case than the ones covered there, because a tip is not merely an unmapped line. It is not a line.

The QuickBooks shape when tips are owed out

If you concluded that your tips are your revenue, you are done, and the default record is correct.

If you concluded that they are owed to staff, here is the shape to aim for. The goal is that tips never touch an income account, and that the balance you owe is visible at any moment without a calculation.

Create a current liability account. Call it Tips Payable. This is where collected tips sit between the moment a customer pays one and the moment you pay it out. It is a balance sheet account, not an income account, and its balance at any date is exactly what you owe.

Get the tip amount out of income and into it. Because the tip arrives inside the sale amount rather than as its own line, this is a reclassification you make rather than something the sync can route for you. Practically, that means a periodic journal entry that debits the income account the tips landed in and credits Tips Payable. Monthly is enough for most businesses; weekly if you pay out weekly and want the balance to mean something between payouts.

Get the number from Stripe, not from an estimate. This is where the field work above pays off. If you collect on-reader, the tip is summable directly from amount_details.tip.amount across the period. If you collect on-receipt, it is the sum of amount minus amount_authorized across card-present charges. Either way it is a real figure from the payment data rather than a percentage someone assumed.

Clear the liability when you pay. Paying tips out debits Tips Payable and credits whatever account the money leaves from. If tips go through payroll, they route through your payroll process and the liability clears there instead. If the account never returns to roughly zero after a payout cycle, something upstream is wrong and the balance is telling you so, which is the main reason to keep it as a real account rather than a spreadsheet.

Decide the product question once. If your tips are your revenue and you simply want them visible, the lighter option is a dedicated QuickBooks product or service item for tips, and a mapping arrangement that routes tipped charges to it. That works when tips arrive on charges you can distinguish. It does not solve the owed-to-staff case, because visibility in income is not the same as being out of income.

The fee question, and what the documentation actually supports

Two things are documented, and one is a consequence of them rather than a separate rule.

Stripe documents that after capture the charge amount is inclusive of the tip. Acodei documents that by default the Stripe fee is recorded "as a negative line using the mapped Stripe-fee product, netting the receipt to what actually entered the balance", and that with fee-as-expense configured, the fee instead posts as a separate purchase or expense and the receipt stays gross.

The consequence: because the tip is inside the amount Stripe processed, it is inside the amount the fee was calculated on, and it settles net in the same balance transaction. If a customer tips $10, the business does not receive $10. It receives $10 less the processing cost on that $10.

For a business keeping its own tips, this is unremarkable and already handled by whichever fee treatment you use. For a business paying tips out in full, it is a real and recurring gap: you owe the full tip and you received slightly less than the full tip, and the difference is a cost of accepting tips on cards. It is small per transaction and not small annually. The two documented fee treatments and what each does to your P&L are covered in how to reconcile Stripe fees in QuickBooks Online.

Confirm the exact split on your own account rather than assuming a rate. The balance transaction for any tipped charge shows the gross, the fee and the net for that specific payment.

If you take tips in person

Nearly everything above assumes a card reader, because that is where tipping mostly happens. The in-person mechanics that sit underneath it, including what a card-present charge carries into QuickBooks and what it does not, are covered in Stripe Terminal and card-present payments in QuickBooks. Worth reading alongside this one if Terminal is new to you, because a tip is one of several things a card-present charge handles differently from an online one.

What to do this week

1. Answer the ownership question. Are your tips yours, or are you holding them for someone? Nothing else is decidable until this is.
2. Find out which tipping method you use. On-reader and on-receipt produce different data and different amounts of work. Check whether your reader prompts for tips, or whether tips arrive by overcapture after the fact.
3. Pull one period's tip total from the payment data. Sum amount_details.tip.amount for on-reader, or amount minus amount_authorized for on-receipt. You now know the size of the problem, which is often the step that settles how much effort it deserves.
4. If tips are owed out, open Tips Payable and post the first reclassification. One entry, one period. The pattern repeats after that.
5. Check a synced record in your own file. Open a tipped charge in Stripe and its QuickBooks record side by side, and confirm where the tip landed. The documentation describes line items resolving through mapping; your own file tells you what that produced for a charge with a tip inside it.

FAQ

Does Stripe separate tips from the sale amount?

It depends on how the tip was collected. With on-reader tipping, Stripe exposes the tip in amount_details.tip.amount on the PaymentIntent, documented as the "Portion of the amount that corresponds to a tip." With on-receipt tipping there is no tip field, and Stripe documents that tips "can be derived from the Charge object" by subtracting amount_authorized from amount. For mandatory tips, Stripe requires the tip to be included in the original PaymentIntent amount, and nothing separates it afterward. In all three cases the Charge object itself carries one amount with the tip inside it.

Are tips revenue or a liability?

It depends on who the money belongs to. If the tip is yours to keep, it is revenue. If you are collecting it on behalf of staff and will pay it out, it is a liability, because you are holding someone else's money rather than earning a sale. The rules vary by jurisdiction and by whether the charge is a voluntary tip or a mandatory service charge, so confirm the treatment for your situation with your accountant once and then apply it consistently.

Why did my Stripe tip end up in a revenue account in QuickBooks?

Because the tip is not a separate Stripe line, and line items are what mapping reads. Acodei documents that sales receipt line items come from Product Mapping, that each Stripe line resolves to a mapped QuickBooks product, and that unmapped lines use the default product. A tip is a portion of the charge amount rather than a line, so there is nothing for a rule to match, and the amount lands with the sale it arrived on.

Does Acodei have a setting to break tips onto their own line?

Acodei's documentation does not describe one. The admin documentation lists Enable Shipping Cost Tracking, which breaks out Stripe shipping as its own line, and Enable Coupon Tracking, which posts coupons and discounts as a separate line item, and there is no equivalent documented for tips. No page in the product documentation covers tips. That is an absence in the documentation rather than a statement that it cannot be done, so check your own file and ask support if this is load-bearing for you.

How do I record tips owed to employees in QuickBooks?

Post them to a current liability account rather than an income account. The common shape is a Tips Payable account, a periodic journal entry moving the tip total out of the income account it landed in and into Tips Payable, and a clearing entry when tips are paid out. If tips are paid through payroll, the liability clears through your payroll process instead. Take the tip total from the Stripe payment data rather than estimating it.

Does Stripe charge a processing fee on the tip?

The tip is inside the charge amount, which is what the fee is calculated on. Stripe documents that after capture the amount is inclusive of the tip, so the tip settles inside the same charge and the same balance transaction as the sale, net of the processing cost. If you pay tips out in full, the difference between the tip collected and the tip received is a genuine cost worth budgeting for. Check the balance transaction on a tipped charge in your own account for the exact gross, fee and net.

Can I collect a tip after the card is already authorized?

In the US, yes, through overcapture, which is what Stripe calls on-receipt tipping. It requires manual capture, an eligible merchant category, and one of Visa, Mastercard, Discover or American Express. Stripe limits overcapture to 50% of the authorized amount or 50 USD, whichever is greater, and directs you to check overcapture_supported on the expanded latest_charge to confirm eligibility for a specific payment.

What is the difference between a null and a zero tip amount?

Null means on-reader tipping was disabled, so the customer was never prompted. Zero means tipping was enabled and the customer declined. Stripe documents both values separately, and the difference is what lets you calculate a tip acceptance rate rather than just a tip total.

The point

A tip is the clearest example of an amount that is legally and practically distinct from the sale it travels with, and technically inseparable from it by the time it reaches your books. Stripe gives you the number, in one of two shapes depending on how you collect it. What Stripe cannot give you is the answer to whether the money is yours, and that answer is what decides whether the default record is correct or quietly wrong every single day.

Work out the ownership question first. Then get the number from the payment data rather than an estimate. The bookkeeping after that is one account and one recurring entry, which is a small amount of work to keep someone else's money out of your income.

Start a free trial and see where each Stripe amount lands in your chart of accounts.

---

Sources: Stripe's PaymentIntent object reference for amount_details and amount_details.tip.amount, collecting tips with Terminal for the on-reader and on-receipt comparison and the mandatory-tip rule, on-reader tipping for the field timing and return values, and on-receipt tipping for overcapture, its limits and eligibility. Acodei behavior is from the product documentation for sales receipts and for the advanced admin toggles.