How to Repeat a Weekly CSV or Excel Report Without Starting Over

You receive a new CSV or Excel export every week. The columns are mostly the same, but the rows have changed. You clean it, join it to a reference file, calculate a few metrics, check the totals, and send a report. Next week, you do it again.

To repeat the analysis safely, keep each dated input, define the metrics once, preserve cleaning and joins as executable SQL or code, run the same validation checks, and compare the new results with the previous run. In Lantide Data, the approved Plan, SQL, validation evidence, and Report can stay together so Codex, Claude Code, or the built-in Agent does not need to reconstruct the workflow from an old chat.

The hard part is not producing one answer. It is preserving enough of the process to rerun it safely and explain why the new answer differs.

This guide uses a weekly inventory report as the example, but the same workflow applies to accounts receivable, sales exports, support tickets, marketing performance, and other recurring file-based analysis.

The example workflow

Assume you receive these files every Friday:

inventory_2026-08-21.xlsx, with one row per SKU and location
product_master.xlsx, with vendor, category, and unit cost
last week's inventory export for comparison

The report needs total stock value, low-stock items, and the largest week-over-week changes by vendor.

A repeatable workflow should answer five questions before producing the final report.

1. Which exact files produced this result?

Keep the dated input instead of overwriting inventory_latest.xlsx. Record the worksheet, file date, and reporting cutoff. If a source is corrected later, you need to know whether the report used the original or corrected version.

For a small workflow, a dated folder is enough:

2026-08-21/
  inventory_2026-08-21.xlsx
  product_master_2026-08-21.xlsx
  previous_inventory_2026-08-14.xlsx

The folder does not make the data correct. It makes the input state identifiable.

2. What does each metric mean?

Write down the grain and definition before running the analysis.

For example:

Grain: one row per SKU and location
Stock value: on_hand_quantity * unit_cost
Low stock: on-hand quantity below the product reorder point
Week-over-week change: current on-hand quantity minus previous on-hand quantity for the same SKU and location

This prevents a later rerun from silently changing from location-level inventory to SKU-level inventory, or from using list price instead of unit cost.

3. Which transformations must be reusable?

Preserve cleaning, joins, filters, and calculations as executable SQL or code. The transformation should include the join keys and any rule for missing reference data.

A simplified comparison might look like this:

SELECT
  current.sku,
  current.location,
  master.vendor,
  current.on_hand_quantity,
  previous.on_hand_quantity AS previous_quantity,
  current.on_hand_quantity - previous.on_hand_quantity AS quantity_change,
  current.on_hand_quantity * master.unit_cost AS stock_value
FROM current_inventory AS current
LEFT JOIN previous_inventory AS previous
  ON current.sku = previous.sku
 AND current.location = previous.location
LEFT JOIN product_master AS master
  ON current.sku = master.sku;

The table names will depend on how your files are loaded. The important part is preserving the logic rather than asking an Agent to invent it again next Friday.

4. Which checks must pass before trusting the report?

Add a small validation gate before the final output:

Count source rows and distinct SKU-location keys.
Check for duplicate keys in current and previous files.
Count SKUs with no product-master match.
Compare total on-hand quantity before and after joins.
Flag null or negative unit costs.

A join can produce a plausible report while multiplying rows. These checks make that failure visible. The CSV data quality checklist provides a broader set of file-level checks.

5. Can the workflow reproduce its own result?

Before replacing the source with next week's file, rerun the workflow against the same inputs. The key totals and exception counts should match.

Then switch to the new dated input and rerun. If a result changes, compare:

source row counts and schema
unmatched and duplicate keys
metric definitions
SQL changes
data cutoff and corrections

The goal is not to force the number to remain identical. The goal is to make the difference explainable. See what reproducible AI analysis requires for the full evidence-chain model.

Where Lantide Data fits

Lantide Data is useful when the recurring task is analytical: combining files, checking joins, calculating metrics, comparing periods, and retaining a reviewable Plan, SQL evidence, and Report.

A practical first test is:

Choose two non-sensitive weekly exports with the same general schema.
Define one comparison metric and two validation checks.
Let the Agent draft the Plan.
Review the grain, joins, and metric definition before Execute.
Keep the approved Plan, generated SQL, and Report together for the next run.

Lantide Data is not intended to replace Excel for complex workbook formatting, formulas, pivot-table editing, email delivery, or scheduled SharePoint workflows. If the job is primarily refreshing an established workbook and distributing it automatically, Power Query, Office Scripts, or Power Automate may be the better fit.

If the job is querying and comparing local files with reviewable SQL, see how Lantide uses DuckDB for Excel and CSV analysis.

A 15-minute first workflow

Use one real but non-sensitive recurring task. Do not upload confidential data or a large production workflow for the first test.

Try to answer:

Could you understand and correct the Plan before execution?
Could you inspect the generated SQL and validation checks?
Could you rerun the same workflow without rebuilding the instructions?
When the result changed, could you locate the reason?

Download Lantide Data. If you test this workflow, send feedback through the Contact page with the task, where you hesitated, and whether you would use the workflow again next week.