From cleaning Excel to managing exceptions with AI

In 60 seconds: If preparing a report means exporting, converting, normalizing, joining, and correcting spreadsheets, a chat interface leaves that work untouched. First design a data schema, deterministic rules, and a quarantine queue. Use AI only to propose interpretations of text or ambiguous cases, always with evidence and human review. The administrative role changes from moving rows to defining rules, resolving exceptions, and improving source data. Measure the result with your own preparation time, rejections, corrections, freshness, and enabled decisions. During the pilot, keep a documented way to produce the report manually.

The meeting may spend an hour on a report that took most of a day to prepare. Someone downloads files from several systems, converts formats, changes delimiters, aligns column names, looks up identifiers, removes duplicates, and checks totals again. By the time the work is complete, the information has another cutoff date.

This is often described as “doing the spreadsheet.” It actually combines three different functions: moving data, applying rules, and resolving exceptions. Separating them makes it possible to automate repeatable work without hiding decisions that need judgment.

Observe the current cycle

Before choosing a tool, follow one real report from end to end:

1. Export: download sales, invoices, payments, or inventory from each system.
2. Convert: open CSV, XLSX, or other files with different encodings, delimiters, and decimal conventions.
3. Normalize: align headers, types, currencies, time zones, and date formats.
4. Join: connect records through a customer, invoice, order, or another identifier.
5. Correct: complete missing fields, investigate duplicates, and decide which version is valid.
6. Report: calculate metrics, document the cutoff time, and deliver the result.

For each stage, record the input file, owner, time spent, rule applied, output, and where a correction is documented. Include failed attempts. Many blank rows after a join may show that two systems identify the same customer in incompatible ways.

To value the work of re-entering or adapting information between tools, the guide to the cost of copying data between systems offers a measurement based on your own cases.

What should be deterministic and where a model can help

Assign each step to the simplest mechanism that can handle it. A predictable rule is easier to test, explain, and repeat.

Situation	Appropriate mechanism	Expected result
A date arrives as 09/13/2026 or 2026-09-13	Parsing with allowed formats and a defined time zone	A valid date or an explicit rejection
The invoice or customer ID is missing	Required-field validation	A quarantined record, never an invented ID
The same source, ID, and version combination appears twice	Unique key and idempotency rule	One processed record and a traced duplicate
Amounts arrive in EUR and USD	Required currency code and an approved exchange-rate table for a cutoff date	A normalized amount with the rate and source recorded
A customer code has an approved equivalent	Master mapping table	A repeatable join between systems
A free-text note says the customer changed its legal name	A model proposes an entity and cites the relevant text	A confidence-scored suggestion for human review
Two customers have similar names and addresses but different IDs	Candidate search and, if useful, assisted classification	Possible matches; a person decides whether to merge them
Someone needs to understand why a record was rejected	A template or a model limited to the case data and rules	A readable explanation that cannot change the rule result

Power Query, SQL, schema validation, and business rules remain the right tools for known transformations. A model should not decide whether 03/04/2026 means March or April, choose a missing currency, or create an identifier just to make a join work. When context is missing, the correct output is an exception.

A workflow designed around exceptions

A reliable process keeps the outcome of every row visible, including those that do not pass.

1. Preserve the input. Store the original file, its source, receipt time, and a fingerprint or version. Never rely only on the edited spreadsheet.
2. Validate the schema. Check columns, types, formats, identifiers, and required fields before calculating the report.
3. Apply quality rules. Detect impossible dates, unknown currencies, malformed amounts, repeated keys, and relationships that do not exist.
4. Split valid data from quarantine. Valid records continue. Every other record keeps its original value, failed rule, and investigation context.
5. Prepare review. Group exceptions by cause and priority. AI may summarize a note or propose candidates, but it must show its evidence and cannot write the official value.
6. Resolve with a human decision. The reviewer corrects the source, approves a mapping, or documents why the record remains excluded.
7. Log and reprocess. Store the actor, timestamp, previous value, approved value, reason, and rule version. Then rerun only affected records.
8. Reconcile the output. Compare counts, totals, and exclusions with the input. Publish the report with its cutoff time and number of open exceptions.

Quarantine should operate as a work queue with an owner, status, age, and closure criteria. If cases build up, the report may still run, but it should state the limit of its coverage.

The administrative role after the redesign

The person who used to move data has essential knowledge. They know which names refer to the same customer, when a credit should not offset an invoice, and which closing period can accept a late correction. The goal is to turn that knowledge into visible controls.

Their work shifts toward:

• defining required fields, reference lists, and acceptance criteria;
• reviewing the queue by risk, close date, or impact on a decision;
• resolving ambiguous matches without silently changing the original value;
• finding recurring causes and requesting a fix in the source system;
• approving rule changes and checking their effect on prior periods;
• explaining what the report covers, what it excludes, and how fresh it is.

Administrative controls remain, concentrated where judgment adds value. Software handles the repeatable transformations that can be verified.

Metrics that show whether the process improved

Set a baseline before the pilot and compare equivalent periods. This lets the team learn without making a savings promise.

Metric	Practical definition
Preparation time	From source availability until the report is reconciled
Rejected records	Count and share sent to quarantine, grouped by rule and source system
Corrections	Changes made during review and corrections made after publication
Freshness	Difference between the latest valid source update and report delivery
Enabled decisions	Specific decisions made with the report, including owner and date, without claiming outcomes that cannot be demonstrated

Add queue age and recurrence by cause if they help run the process. Lower preparation time with more post-publication corrections is not an improvement. Neither is a fresher report that silently omits records.

The first week of the pilot

Choose one recurring report, one version of its schema, and one exception owner. Limit the sources and do not replace the official report yet.

• Day 1: document the current path with a recent sample and measure time, known rejections, corrections, and cutoff time.
• Day 2: define columns, types, identifiers, currencies, date formats, and join rules. Prepare valid and invalid examples.
• Day 3: run the rules alongside the manual process. Test missing data, duplicates, unknown currencies, ambiguous dates, and unmatched IDs.
• Day 4: open the quarantine queue to its owner. Check that every case shows origin, reason, evidence, and an available action. If a model is involved, evaluate its proposals without allowing automatic writes.
• Day 5: reconcile both results, review the metrics, and decide which rule to adjust, which issue to return to the source, and what should remain manual.

The guide to what a business should automate first can help narrow the pilot by value, readiness, and risk. If management later needs to query the results, the assistant connected to ERP, sales, and collections covers the access architecture; it does not replace this data-quality work.

Manual recovery before launch

Document the fallback while the current process still works. Define who can stop the automation, where to find the latest original files, which manual template is approved, and how long the team needs to rebuild the report.

When something fails, freeze new runs and record the cutoff time. Recover the source files, identify the last reconciled output, and continue with the manual template from that point. Keep already processed records and their IDs separate to avoid duplicates. When the automated flow returns, first reprocess a copy, compare counts, totals, and exceptions against the manual result, and only then publish a new version.

The plan should also say how to communicate a delayed or partial report and how to roll back a faulty rule. A recoverable automation leaves enough inputs, versions, and decisions to reconstruct what happened.

The process improves when invisible corrections become explicit rules, owned exceptions, and reports whose quality can be explained. The interface is secondary. AI has a useful, limited role there: it helps investigate ambiguity while people retain the decision.