Spending by merchant

Give the rule a name you recognize

A statement might say CAFE 01 on Monday and CAFE 02 on Tuesday. If you know those descriptions belong together, add a contains rule for CAFE and give it a merchant label and category. The tool keeps both original descriptions beside your labels; it doesn't replace the bank's wording with a guess.

The fictional example has two cafe purchases, 4.50 and 5.50, and a 2.00 credit. Its confirmed CAFE rule produces purchases of 10.00, refunds or other credits of 2.00, and net out of 8.00 USD. The 20.00 GROCERY purchase stays unclassified because there isn't a rule for it. All four rows remain in the result.

Order matters. Put a REFUND rule above CAFE and the credit moves to your Refund review group. The row still lists both matches and an overlap warning, so that change can't disappear into the total. A manual row override wins over every rule, including an explicit decision to leave the row unclassified.

A label is your decision, not a merchant lookup

Contains matches any literal substring. CAFE can match CAFE 01, but also a longer word containing those letters. Exact description is narrower: after matching-key normalization, the whole description must match. Neither option uses regular expressions, a merchant database or AI.

PAYPAL is a useful example of why that distinction matters. It can identify a payment intermediary without identifying the seller. Use a more specific rule or review the row yourself. Categories are user-assigned labels, not findings about real-world merchant identity or tax deductibility.

The purchase and credit columns are sign buckets, not a judgment about why money moved. A positive row might be a refund, wages or a transfer. Card payments and transfers are not automatically removed, so this is a summary of supplied rows, not all your spending. It provides no tax, legal, lending or accounting advice, no fraud or document-authenticity judgment, and no guarantee that another app will accept the downloads.

Check the columns before trusting the totals

Choose the date column and say whether it records posted or transaction dates. Then confirm the date order, number format and amount direction. The tool doesn't settle ambiguous dates for you. Negative means money out after your sign choice; card exports with positive purchases need the reverse setting. Debit and credit columns have their own explicit direction choice.

Totals stay separate for each account, currency, merchant label and category. Account identifiers stay as text, including leading zeros. Currency and account labels are case-sensitive after trimming their ends. Every amount uses the decimal precision you select, from zero to six places; excess precision is rejected rather than rounded, and there is no currency conversion.

Only matching keys are trimmed, Unicode-normalized and case-folded. Digits, internal spaces and accents still matter, although compatibility forms such as full-width letters are normalized. Original descriptions remain available in the row report. Missing descriptions stay flagged and unclassified unless you apply a manual override.

The limit is one UTF-8 file of up to 5 MB, 10,000 data rows and 100 rules. Invalid dates or amounts, blank records, repeated headers and subtotal-like rows block the summary rather than quietly reducing it. Review the issue list and fix a working copy. Time or weekday text removed from dates is listed for your confirmation. The observed first and last transaction dates don't prove that the history between them is complete.

Downloads contain all calculated rows, not just the visible table page. The summary CSV keeps groups separate, and the annotated CSV records source lines, original cells, matching rules, overrides and your format choices. These are review worksheets, not files tailored to an accounting importer.

Your rules don't become a saved profile

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.

That includes merchant rules, account labels and row overrides. Rule export is a separate, explicit JSON download; there is no automatic save or rule import. Clear all clears the active input and rules. Back navigation can restore uncleared input, and clearing the tool is not secure erasure of your browser's history or files you already downloaded.

The spreadsheet-safe CSV prefixes formula-like text with an apostrophe. Parsed negative amounts stay numbers, while the faithful machine CSV preserves unescaped text for a trusted non-spreadsheet reader. Spreadsheet software can remove protective prefixes when saving or reopening CSV, so inspect the file before using it elsewhere. Neither download overwrites your original. Treat detailed exports and rule files as private records, not something to forward with the tool's link.

If the history you need is still in PDFs

Already have a bank CSV? This tool is free. Only have PDF statements? First check your bank's native export or any included extraction option. AnyStatement can convert PDFs into reviewable transaction data. Check that data against the statements before applying rules; a neat category doesn't repair a missing transaction.

Keep the evidence beside the labels

For a repeatable review, use the statement review log to record what you checked. The CSV checks guide covers the source-data checks, and bank statements as tax records explains why a category total doesn't replace supporting documents.