An incorrect-amount chargeback should be treated as arithmetic. The merchant needs to reconstruct the amount the customer agreed to, the authorization, the capture, taxes/tips/shipping or other adjustments, refunds, and the amount now disputed. When those numbers are presented in one bridge, many cases become obviously defensible or obviously merchant error.
Start with transaction-specific records and avoid broad statements about how the business usually calculates totals. The case should explain this amount, on this order, through every financial change.
Freeze the agreed price
Save the purchase-time order, invoice, signed receipt, or booking showing subtotal and relevant components. If prices changed later, do not use the current catalog as evidence.
For variable-price services, preserve the estimate, approved change order, meter/usage record, or other basis for the final amount where applicable.
Compare authorization and capture
List authorized amount, capture amount, timestamps, and transaction IDs. If multiple or incremental authorizations exist, keep them separate and map them to the final charge.
A final receipt does not prove the higher amount was properly authorized; the payment record must also reconcile.
Break out adjustments
Show tax, gratuity, shipping, deposit, incidental, surcharge where lawful/applicable, or other components individually. Use the transaction record that supports each line.
Do not hide an unexplained difference in a single 'adjustment' row. If the merchant cannot explain it, treat it as an investigation gap.
Check partial refunds and credits
List every credit with amount, timestamp, status, and processor reference. Then calculate the net retained amount.
A dispute for the original gross amount may be affected by a completed partial refund, while a pending refund may not yet have reduced the customer's posted balance.
Build the amount bridge
Use a table from agreed subtotal to final net retained amount. Each row should point to an exhibit. The disputed difference should be visually obvious.
Keep the narrative to one or two sentences explaining the difference. Reviewers should not need prose to perform basic arithmetic.
Find the source of amount errors
Trend discrepancies by POS, tax engine, tip workflow, shipping adjustment, manual entry, installment logic, or API integration. Fix the system that changes amounts unexpectedly.
A good dispute operation treats incorrect-amount cases as payment-quality defects, not just representment opportunities.
Example: a legitimate tip adjustment versus a keying error
A restaurant authorizes $80 and later captures $96 after the customer signs a receipt with a $16 tip. That is a different fact pattern from a cashier accidentally entering $106 at capture. Both can produce an 'incorrect amount' complaint, but the evidence and outcome should not be treated as interchangeable.
Reconcile the amount step by step: listed or agreed price, tax, authorized amount, customer-approved adjustment if applicable, final captured amount, refund or correction, and disputed amount. The arithmetic should explain the charge without requiring the reviewer to infer why the number changed.
Use a reproducible amount formula
Write the final amount as a formula the reviewer can reproduce—for example base price + tax + customer-approved tip - completed refund = retained amount. Reference the source record for each term. This exposes unsupported surcharges, double-applied tax, currency mistakes, and manual capture errors faster than narrative prose.
If the merchant cannot produce a clean formula from contemporaneous records, stop adding screenshots and investigate the payment flow. Incorrect-amount disputes often reveal POS, integration, or staff-process defects that should be fixed even when the individual case value is small.
For marketplaces or multi-merchant carts, calculate the challenged merchant's component separately from the platform order total. A correct global total can still hide a wrong sub-merchant capture, tax allocation, or adjustment.
Use a reproducible amount formula instead of a narrative about the total
An incorrect-amount case should be reducible to a formula. Start with item or service subtotal, then add tax, shipping, tip, deposit, approved add-on, quantity change, or other documented component, and subtract discounts or credits. The formula should equal the settled amount. If it does not, identify the unexplained difference before drafting. A merchant should be able to hand the calculation to a second reviewer who can reproduce it from source records.
Keep authorization and capture as separate inputs. If the final amount legitimately changed after authorization, show when and why. Restaurant tips, hotel incidentals, fuel, partial fulfillment, and custom work can create valid adjustments under specific payment rules, but the evidence still needs the customer or contractual basis and provider transaction path. Do not use a generic 'final amount can vary' statement where the live transaction lacks a supported adjustment.
Partial refunds should be subtracted from the economic amount still in dispute. If a $180 sale received a $30 refund, show the $150 retained balance and why it remains. If the customer disputes the full $180, the completed $30 credit must be prominent. If the merchant's refund failed, do not subtract it as though money moved. Use the processor status and transaction identifier.
Track amount errors by source system. Common causes include manual keying, tax recalculation, tip entry, duplicate add-on, stale cart total, shipping adjustment, currency bug, or staff override. Add validation where the captured amount diverges from the order total beyond an expected tolerance. A good evidence packet explains one amount; a good payments system prevents unexplained totals from settling in the first place.
Reconcile taxes and discounts at the line-item level when totals changed
Taxes and promotions can produce amount differences that are difficult to explain from a final receipt alone. Preserve the item-level calculation used at checkout, including discount allocation, tax jurisdiction, shipping, and any later recalculation. If a line was removed or returned, show how the adjustment changed tax and discount amounts. The final total should be reproducible from the same rules the commerce system used.
When a software release changes tax or discount logic, tag affected orders by version. A cluster of incorrect-amount disputes after one release can be identified quickly if the merchant can connect payment totals to the pricing engine that generated them.
Keep gratuity and tax changes traceable to the final customer receipt
When tips or taxes change after the initial amount, preserve the final receipt or customer-facing record that reflects the captured total. A back-office calculation is less persuasive if the customer never saw the adjustment. For manually entered gratuities, retain the normal record used by the business and audit suspicious or unusually large edits. For tax changes, keep the jurisdiction and calculation source. The amount bridge is strongest when payment-system arithmetic and the customer-visible total agree.
Amount disputes should be reconstructed as arithmetic the reviewer can verify. Start with the agreed base price, then list taxes, shipping, tips, deposits, credits, discounts, upgrades, and post-service adjustments in the order they occurred. Connect each component to a receipt, order event, or authorization record. If the final captured total differs from what the customer first saw, identify the legitimate event that changed it. Do not make the reviewer infer the bridge from several screenshots with different totals. This method also exposes genuine merchant errors: a duplicated gratuity, stale tax calculation, manual surcharge, or second capture often becomes obvious once the amounts are placed in one ledger.
VERIFY CURRENT RULES
Primary references
Processor interfaces, reason-code mappings, filing windows, and network rules can change. Check the active dispute notice and current official documentation before submitting.