Check a promised refund
Refund match checker
A matching amount isn't enough to identify a refund. Compare what you expect with posted credits, allocate the amounts yourself, and keep unexplained credits visible. Your CSV stays in this browser tab.
By AnyStatement
Published , 4 min read
The example is fictional. Allocate 30.00 and 49.99 to Return A to reach 79.99. The unrelated 19.99 and the second 79.99 credit stay unallocated, totaling 99.98, unless you have a reason to assign them. Loading the example does not confirm any match.
One account and currency
Unmapped account and currency use these labels. If you map those columns, every value must match them exactly. Nothing is pooled across accounts or currencies. Changing active sources or settings removes existing confirmations and allocations.
Which credits were posted?
UTF-8 .csv or .txt, up to 5 MB. File contents never leave this tool.
Use one account's posted rows, not pending activity. Positive normalized amounts below mean money back to the account holder. Debits and zero rows stay visible but cannot be allocated.
Two-digit years
At 69, years 00 to 68 mean 2000 to 2068; 69 to 99 mean 1969 to 1999. Prefer four-digit years. Printed calendar dates are used without timezone conversion.
Enter expected refunds by hand instead
This is a draft list. Use it below to replace the expected-refunds CSV and clear existing allocations. Amounts use a decimal point and the worksheet's selected decimal places. All entries use its account and currency.
What refund do you expect?
UTF-8 .csv or .txt, up to 5 MB. File contents never leave this tool.
Map your reference to Reference, merchant label to Description, earliest search date to Date, and expected positive amount to Signed amount. Last search date is optional.
Two-digit years
At 69, years 00 to 68 mean 2000 to 2068; 69 to 99 mean 1969 to 1999. Prefer four-digit years. Printed calendar dates are used without timezone conversion.
File read: Waiting for both readable inputs.
Format checks: Not ready. Resolve the input messages above.
Allocation worksheet: Not calculated. No merchant or bank confirmation is performed.
Start with the refund you expect
Enter a reference, merchant label, positive expected amount and earliest search date. You can type a draft list or supply a second CSV; a last search date is optional. Add your posted statement CSV, map the columns and choose the dates, number separators and sign convention. Use one account and one currency. If those labels are mapped, every row must match the worksheet labels.
The merchant label doubles as a visible literal description rule. Choose an exact match or a contains match. Suggestions also need the same account, currency and an inclusive date-window match. Matching ignores case and Unicode presentation differences, not arbitrary spelling differences. A credit with the exact expected amount sorts first, but the tool never allocates it for you.
Choose a candidate and enter the amount you want to assign. Several credits can cover one expectation, and one credit can be split across expectations. You cannot allocate more than the credit supplies or more than the expected refund. If a description differs, show every available credit in the selected window and review the original text yourself.
Two partial credits, one expectation
In the fictional example, Return A expects USD 79.99. You allocate 30.00 from one Maple Shop credit and 49.99 from another: 30.00 + 49.99 = 79.99, leaving 0.00 of the expectation unallocated. The unrelated 19.99 credit stays available. So does a separate Maple Shop credit of 79.99, even though its amount matches perfectly.
The two unused credits total 19.99 + 79.99 = 99.98. Across all four supplied credits, 179.97 = 79.99 allocated + 99.98 unallocated. The label is “fully allocated by you”, not “refund received”. The example loads without allocations so you can make those decisions explicitly.
An empty match is not a missing-money finding
This worksheet checks your allocations against your supplied rows. “Partly allocated” and “no allocated credit in supplied data” describe the worksheet, not whether the merchant issued a refund or owes you money. Other cards, missing dates, a different description or a different currency can leave the question open. Coverage is never assumed complete.
Stripe's refund documentation explains that some refunds appear as reversals: the original charge disappears and no separate credit is issued. Its refund instructions also allow partial and multiple refunds. Those are examples of why statement matching needs context, not a universal rule about every bank or payment method.
Review negative rows that might reverse a previously allocated credit. Nothing is automatically netted; remove the affected allocation and check the source. This tool does not issue or trace refunds, assess entitlement or document authenticity, recommend chargebacks, calculate deadlines or confirm a merchant's or bank's records. File reading, format checks and allocation arithmetic remain separate states.
Keep the original evidence
Each UTF-8 CSV input is limited to 5 MB (5,000,000 bytes). The worksheet accepts 10,000 statement rows, 100 expectations and 1,000 explicit allocations. Tables are paged. Choose zero to six decimal places; excess precision is rejected, not rounded. Enter allocation amounts with a decimal point and no grouping.
Pending activity does not belong in this worksheet. You must declare that the statement contains posted transactions only and that its mapped date is the posted date. If it includes pending rows, prepare a posted-only working copy first and keep the original. Blank records, repeated headers, subtotal candidates, malformed values and inconsistent mapped labels block calculation, with their source lines retained for review. Exact duplicates remain distinct and are flagged, not deleted.
All positive credits stay in the report, including unrelated credits and those outside every search window. Nonpositive rows remain visible but cannot be allocated. Changing active input or settings clears prior confirmations and allocations. Keep a separate note of unresolved questions in the statement review log.
Private calculation, deliberate downloads
Your file and the values you enter are processed in this browser tab. They are not uploaded or sent to analytics. We do not save them between visits. Downloads you choose to save remain on your device.
Use Clear all inputs and results when you finish. Back navigation can restore uncleared input; clearing does not promise secure erasure of browser memory or device history. Ordinary site requests load the page, but do not carry your worksheet.
The review download includes both source identities, original cells, source lines, expectations, credits, allocations and assumptions. Check it before sharing. The short summary omits merchant and account names. Protected CSV downloads prefix formula-like text with an apostrophe without changing parsed negative amounts; the changed-cell count is shown. As OWASP explains, spreadsheet save/reopen can remove such protection. The unprotected text export requires a separate warning acknowledgement. Neither export overwrites your input.
What was checked
The fictional arithmetic was recomputed with exact decimals, and the allocation logic has tests for partial credits, over-allocation and unmatched expectations. Stripe's refund documentation and OWASP's CSV injection guidance were opened on October 17, 2026; neither showed an update date. The CSV structure follows the shared parser built around RFC 4180 (October 2005), also opened that day. No real refund was traced, and no bank or spreadsheet import acceptance is claimed.
If the credits are still in PDFs
First check your bank's native CSV export. If only PDF statements remain, AnyStatement can convert them into reviewable transaction data with source-line links. That is a separate upload workflow, not a requirement to use this free checker. This page does not send your file to it.