Muse for Spreadsheets and Data Habits: Clean Exports, Sanity Checks, and Reports That Match the Numbers
A spreadsheet setup for Muse: clean the messy export without touching the original, sanity-check every total before you trust it, and turn the table into a short written report, with a change log and a review list on every run.
By Professor Muse13 min read
Most spreadsheet work is not analysis. It is janitorial work that happens before analysis can start: the export arrives with three date formats, a total row sitting in the middle of the data, category names spelled four ways, and two hundred rows that are actually the same customer. You clean it by hand, you build the report, and next week the same export arrives with the same mess. The cleaning eats the morning, the report gets written from numbers you stopped checking, and nobody notices until a total is wrong in front of someone who matters.
This lesson sets up three jobs that run on a schedule instead of on your patience. Muse cleans the export, checks the numbers against the source before anyone trusts them, and turns the clean table into a short written report. You keep the original file untouched, you read the change log, and you send the report. The numbers in it are the numbers in the file, with a paper trail between them.
The pattern behind the cleaning job is the difference between a workflow you can trust and a chatbot rewriting your ledger. Ask for a plan, not a result. Muse profiles the file first, proposes the cleaning steps, applies them with code rather than by retyping cells, and then verifies row counts and totals before writing anything out. Judgment calls on messy values go to a review list for a person, never into silent edits. That is the shape this lesson follows.
The short version
- Clean every export the same way: profile the file, get a cleaning plan, apply it with code, and verify row counts and totals before anything is written out.
- Never edit the original file. The clean version goes in a new tab or file, with a change log and a review list beside it.
- A total is only trusted when it is recomputed from the clean data and matched against the source. A number Muse typed out is not a checked number.
- The failure mode to watch for is a row that disappears or a total that drifts during cleanup. The fix is a count and total check on every run, with the run failing loudly instead of writing a partial result.
The Setup: The Friday Sales Report
Call the whole arrangement the Friday Sales Report. I run a small online shop, and every Friday morning the same file lands: a Shopify orders export for the week, about 400 rows, with order numbers, dates, customer names, product names, quantities, and totals. The same file, the same mess. Dates arrive as 11/2, Nov 2, and 2026-11-02 in the same column. Product names arrive as “Mug - Blue”, “blue mug”, and “MUG BLUE”. A subtotal row sits in the middle of the data every few weeks because someone exported with the summary turned on. The report I need is short: total revenue, orders, average order value, the top five products, and anything that looks off.
The setup has four parts, and they never change. The original export stays read-only in its folder. The clean version goes into a new file, with a change log tab listing every edit and a review tab listing every value Muse could not decide on. A standing instruction from our memory guide holds the rules: never edit the original, never delete a row without logging it, never merge two rows unless they match exactly on order number, and never write a total Muse did not recompute from the clean data. The Friday run is a scheduled routine, the same shape as a Friday expense review, and it ends with a short written report I read before it goes anywhere.
The same discipline carries into the finance version of this job:
Prompt 1: Clean the Export
Run this on the raw file, every time, before anything else. The prompt asks for a plan first and a result second, and it forbids the one thing that causes most cleanup damage: Muse retyping the data.
Clean the attached export into an import-ready table. Work in this order. (1) Profile the file: for each column, report the number of blank cells, the distinct values, the formats you see, and any rows that do not look like data, such as subtotal lines, repeated headers, or notes. (2) Propose a cleaning plan as a list of operations: which columns to trim, which date formats to parse, which values are the same category under different spellings, which columns to split, and which rows to remove, with a reason for each removal. Stop here and show me the plan. Do not edit anything yet. (3) After I approve the plan, apply it with code, not by retyping cells. Write the clean table to a new file, never the original. Add a row ID to every row so each clean row links back to its source row. (4) Write a change log listing every edit, and a review list of values you could not decide on, each with the allowed options. Do not guess a category for a value on the review list. Do not merge two rows unless they match exactly on order number.
File: [attach the export]. Target columns: [list the columns the clean table must have, and the required fields]. Allowed categories: [list the standard category names, if you have them].
Read the plan before you approve it. The plan is where the judgment lives, and a plan that merges two customers or drops a column is cheap to catch before anything is applied. Once the plan is approved, the same plan works next week on the next export, with only the review list changing. That is the point at which the job stops being a weekly chore and starts being a routine.
Two details from the profile step: First, leading zeros and long numbers: opening a CSV in Excel strips leading zeros from ZIP codes and truncates IDs longer than 15 digits, so read those columns as text from the start. Second, header rows that move: a supplier adds a logo row or a second header line, so the profiler should find the real header row instead of assuming it is row one. Both of these show up in the profile if you ask for it, and both are invisible if you do not.
Prompt 2: Sanity-Check the Numbers
Run this on the clean table, before the report is written. A clean table is not a correct table. Cleaning can drop a row, change a total, or turn a number into text, and the only defense is recomputing everything from the clean data and comparing it against the source.
Sanity-check the clean table against the original export. (1) Row count: the clean table must have the same number of rows as the original, minus the removals listed in the change log, with each removal named. List any row that is missing without a logged reason. (2) Totals: recompute the total for every numeric column from the clean table and compare it with the total from the original export. Report both numbers for every column. If a total differs by anything other than a documented removal, stop and say so. (3) Required fields: confirm every required field is filled in every row, and list any row where it is not. (4) Outliers: list the five largest and five smallest values in each numeric column, and any date outside the expected range, so I can see whether a misplaced decimal or a wrong year slipped through. Do not fix anything in this step. Report only.
Clean table: [attach the clean file]. Original export: [attach the original]. Expected date range: [the week the export covers]. Required fields: [the fields that must never be blank].
Work the report the way you would work a bank statement: the totals either reconcile or they do not, and a difference of one row is a difference worth chasing. If the check finds a mismatch, the cleanup runs again with the plan corrected, and the report waits. A report written from unchecked numbers is a guess with formatting, and it will be quoted as fact the moment it leaves your desk.
This is the same rule our finance teams lesson holds for variance notes: never invent a figure, and never carry a number forward that was not recomputed from a source you can open. The spreadsheet version of that rule is the count and total check, run every week, with no exceptions for weeks when the export looked clean.
| Job | When | What it answers |
|---|---|---|
| Clean the export | When the file lands | Is the table consistent, deduplicated, and traceable to the source |
| Sanity-check the numbers | After cleaning, before the report | Do the row counts and totals reconcile with the original |
| Build the report | After the check passes | What happened this week, in plain language, from the checked numbers |
Prompt 3: Turn the Table Into the Report
Run this only after the sanity check passes. The report is short: the numbers that changed, the products that drove them, and the rows that need a human decision. A report that repeats the whole table is a table with sentences around it, and nobody reads it twice.
Write the weekly report from the clean table below. Keep it under 300 words. Include: (1) total revenue, total orders, and average order value, each with last week’s figure for comparison, (2) the top five products by revenue, with units sold, (3) any category where revenue moved by more than 20 percent from last week, with the direction of the move, and (4) the open items from the review list, one line each, naming the value and the decision needed. Rules: every number must come from the clean table. If a figure cannot be computed from the table, say so instead of estimating it. Do not add commentary about why a number moved unless the table itself shows the cause. End with the review list as a separate section, so the decisions are visible without reading the report.
Clean table: [attach the clean file]. Last week’s report: [paste last week’s figures for comparison].
Read the report against the clean table before it goes out, the same way you read the plan before approving it. Check the three headline numbers first: revenue, orders, average order value. If one of them is wrong, the rest of the report is decoration. The review list at the end holds the decisions only a person can make, and it shrinks every week as the standard categories settle.
If you run a personal version of this job, the same three prompts work on your own statements. Our personal finance lesson runs the same discipline on bills and subscriptions, with every number tied to a statement you can open. The shape is identical: clean, check, then summarize. Only the file changes.
What Can Go Wrong: The Row That Disappears
Here is the failure mode you will meet first. The clean table comes back tidy, the report reads well, and the revenue total is lower than last week by the exact value of one order. The cause is a row that vanished during cleanup. The model rewrote the table as text instead of applying edits with code, and one row in the middle did not make it into the output. Nothing flagged it, because nobody checked the row count, and the total that came back was the total of the rows that survived, not the total of the week.
The fix has three parts, and all three are already in the prompts above. First, Prompt 1 forbids retyping: edits are applied with code, and every row carries an ID linking it to its source row. Second, Prompt 2 checks the count before anything is trusted: the clean table must reconcile row for row against the original, minus documented removals. Third, the run fails loudly: if a total differs by anything other than a documented removal, the report does not get written, and Muse says so instead of producing a plausible-looking number.
The same caution applies to over-eager deduplication. Two rows for different customers with the same name are not duplicates, and merging them deletes a real order. The standing rule handles it: only exact matches on a strong key, like the order number, merge automatically. Near matches go to the review list, where a person decides. A review list with five items on it means the workflow is doing its job. A clean table with no review list and a total that drifted is a workflow that failed quietly, and quiet failure is the only kind that costs money.
Our failure modes guide covers this pattern in general terms: a fluent output that reads cleanly gets less checking than a rough one, and the checking it skips is exactly the checking that would have caught the error. The check is a count and a total, so there is no reason to skip it. Run it every week, even on the weeks when the export looked clean. The week it catches something is the week it pays for the whole setup.
Start With One File
Do not build the whole Friday Sales Report this week. Take the last export you cleaned by hand and run Prompt 1 on a copy of it, with the original kept read-only. Read the plan, approve it, check the change log and the review list, then run Prompt 2 and confirm the counts and totals reconcile. Run Prompt 3 only after the check passes, and read the report against the table before you send it.
Run it that way and Muse does what it is good at with spreadsheets: the profiling, the plan, the repetitive edits, the recomputation, the short summary. You keep what was always yours: the original file, the decisions on the review list, and the final read before anything goes out. That gives you a weekly report that matches the numbers in the file, a change log that shows every edit, and a review list that gets shorter as the categories settle. The discipline that holds it together is the count and total check, run every time, with no exceptions.
The clean-up pattern in this lesson, profile the file, propose a plan, apply edits with code, verify row counts and totals, and keep the original untouched with a change log and review list, follows the guide to cleaning messy spreadsheets with AI published by Lumeor Studio, which describes the same sequence for recurring exports.
