Separate item, tax and shipping amounts in a refund

Reconstruct the requested composition from the original order

Open the original order and the actual refund decision together. Identify the affected item lines, their recorded quantities and amounts, the tax entries and the shipping charge. Use the order values as recorded at purchase rather than today’s catalog prices or shipping rates. Keep any recorded discount treatment visible so that a merchandise subtotal is not confused with an undiscounted price.

Write the scope of the request separately from the approved decision. A request for an item refund does not tell you whether shipping was included, and a total alone does not explain its tax component. If the decision is silent about a component, record that uncertainty instead of assigning the remainder to shipping or tax merely to make the figures add up. Any additional order component needs its own labeled line in your working reconciliation.

Record whether the administrator entered quantities or money

WooCommerce’s refunds guide distinguishes item quantities from manually entered refund amounts. That distinction affects automatic tax calculation. Preserve which fields were entered and inspect the resulting item and tax amounts; do not assume two entry methods produced the same composition because the headline total looks right.

Compare each recorded component with its approved amount. Keep the merchandise amount and its tax separate, and distinguish the shipping amount from any separately recorded shipping tax. Where the display combines values, establish whether a total already includes tax before adding anything. This check identifies a possible omission or double count in the reconciliation; it does not decide the tax treatment required for the order.

A refund history may establish the saved amounts without preserving every keystroke that produced them. If the entry basis cannot be established from retained records, mark it unknown. The saved component values can still be compared. Do not recreate a refund to discover which input path someone used.

Match this refund to the provider without losing the component detail

Total the recorded refund components once, in the order’s currency, and compare that result with the amount and currency of the corresponding provider refund. Use the original payment and refund references privately to make the match. A payout or net balance movement is not a substitute for that refund amount. Keep earlier refunds separate so that this request is not compared with a cumulative total.

WooCommerce manual refunds record a refund without themselves returning funds, and changing an order status alone does not move money. Automatic refunds require gateway support. Therefore, a store total with no confirmed provider match is a record awaiting reconciliation, even if its item, tax and shipping arithmetic is internally consistent.

When Stripe is the actual provider, cumulative partial refunds cannot exceed the original charge. Stripe also distinguishes refund states and available-balance constraints. Those facts do not identify the item or shipping allocation on your order, and an amount match does not establish that the refund has completed. Record the provider’s actual state alongside its total.

Resolve the specific difference before another refund action

If the approved components and store entries disagree, name the particular line and amount that differ. If the store total and provider refund disagree, name the unmatched refund reference, currency or amount. These are different problems: changing a tax allocation in the working sheet cannot explain a missing provider refund, and another payment action is not a way to repair an unclear allocation.

Keep a dated explanation with the existing records and assign the unresolved component to the person authorized to decide it. Ask the responsible tax adviser about tax treatment when that is the missing decision. Ask the gateway owner about the actual payment record when that is the gap. Do not issue another refund solely to make two screens agree.

For a Prism checkout-review consultation, describe the platform, the input method if known, and the component that failed to reconcile. Scope, responsibilities, fees and terms are confirmed before work. Keep the full order, customer details and payment credentials in your authorized systems.

Refund component reconciliation

Use one copy for one actual refund. In the final column record requested or approved amount, saved store amount, and any difference for each component. Separate tax-inclusive totals before adding them. Unknown is not zero. A component match and a provider-state check are separate conclusions.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.