Public evidence index / analyst operations

Preview spreadsheet cleanup before a workbook becomes a reporting source

This is the evidence and fixed pilot contract for a proposed Microsoft Excel cleanup add-in and Power BI handoff. It is for an analyst, reporting lead, or data steward who has inherited a workbook full of inconsistent identifiers, text-formatted numbers, mixed dates, duplicate-looking rows, and values that should not be normalized without a review trail.

Request the $249 pilot scope

$249 onceOne review-only founding-team pilot; no automatic renewal.
Ten sheetsUp to ten accepted worksheets and one declared reporting purpose.
10 business daysAfter scope, file-handling terms, and a non-sensitive acceptance fixture are agreed.
Zero writesThe pilot returns a preview and does not overwrite the source workbook.

No Office add-in, Power BI connector, Partner Center account, Marketplace listing, checkout, contract, customer file, or subscription exists for this test. The request form takes no payment and does not accept a workbook upload.

The fixed pilot deliverable

An analyst at a finance, operations, or reporting team pays $249 one time for a review-only cleanup preview covering up to ten accepted worksheets, delivered within ten business days as a CSV transform log, a cleaned preview copy, and a human-readable HTML receipt. The receipt records before-and-preview-after counts per sheet. There is no subscription and therefore no renewal to cancel. Scope acceptance and data-handling terms happen before payment; this page only tests whether a buyer requests that scope.

Included

  • A structural inventory of sheet names, used ranges, column headers, formulas, merged cells, and declared types relevant to the agreed reporting purpose.
  • Deterministic normalization proposals for accepted identifier, date, country, currency, whitespace, case, null, and enumeration rules.
  • Duplicate candidates grouped by the exact comparison keys the buyer approves, with every source row retained for review.
  • A cell-level transform log naming the sheet, cell, source row, original value, proposed value, rule, and confidence.
  • Before-and-preview-after counts for rows, proposed normalizations, duplicate groups, unresolved cells, and source writes.
  • A Power Query handoff note describing which preview columns can enter a Power BI model and which unresolved fields remain review-only.

Not included

  • No silent overwrite, row deletion, formula replacement, macro execution, external-link refresh, workbook upload from this public page, or unattended publication to Power BI.
  • No claim that a duplicate-looking row represents the same person, customer, account, or transaction without a buyer-approved comparison rule.
  • No inference of missing financial, identity, legal, compliance, tax, or business facts, and no replacement of an unsupported cell with a guessed value.
  • No review of passwords, protected health information, payment-card data, government identifiers, private credentials, or material outside the accepted scope.
  • No guarantee that a future add-in will pass Microsoft certification or work on a platform absent from its tested manifest requirements.

Preview-only acceptance rule. Every proposed cleanup names its sheet, cell, original value, proposed value, and rule; the pilot applies zero silent workbook writes. Every unresolved cell stays unresolved. Duplicate candidates stay in a human review queue. The buyer decides which transformations, if any, to apply to a copy after delivery.

What the public reference receipt demonstrates

The public receipt is generated from a synthetic two-sheet workbook fixture with 8 rows. Before the preview, the fixture contains 9 deterministic normalization candidates, 2 duplicate candidate groups, and 2 cells that cannot be parsed under the declared rules. The preview proposes 9 normalizations, queues both duplicate groups for human review, keeps 2 cells unresolved, retains all 8 rows, and applies 0 source writes.

That distinction matters. A green cleanup total can hide destroyed formulas, coerced identifiers, or a date interpreted under the wrong locale. The receipt instead preserves the original value beside the proposal. A value such as N/A remains unresolved until the buyer says whether it means missing, not applicable, or literal text. A value that does not match an accepted date format remains an error rather than becoming a confident date. A duplicate group names its source rows and comparison evidence; it does not delete either row.

The receipt's five structural checks pass: every proposed operation names a sheet, cell, and source row; every operation preserves the original value; every duplicate names its source rows; unparseable values remain unresolved; and no source writes are applied. This is real evidence for the transform-log schema. It is deliberately not evidence of an Office add-in, a Power BI connector, customer compatibility, security review, marketplace approval, or buyer demand.

Inspect the machine-readable synthetic reference receipt.

How the transform log protects an analyst

Spreadsheet cleanup is risky when the action and the evidence are separated. A row count falling after “remove duplicates” says nothing about which records were removed or why. A currency column becoming numeric says nothing about whether commas and periods followed the intended locale. A date column parsing successfully can still be wrong if day and month were reversed. The pilot therefore treats every transformation as a reviewable decision with a stable source location.

Each log row carries the original workbook identity supplied at intake, the sheet, source row, cell, column, original value, proposed value, deterministic rule, and confidence. The report groups those rows into exact transformations, review-required candidates, and unresolved values. Before-and-preview-after counts are recomputed from those log rows rather than typed into a narrative. A Power Query handoff may consume the accepted preview, but it never turns an unresolved field into a clean field merely because a downstream model expects one.

The pilot also separates data cleanup from business interpretation. It can show that two rows normalize to the same declared comparison key. It cannot prove that two people are the same person or that two invoices are the same obligation. That conclusion belongs to the buyer and the records available to them. This evidence boundary is more useful than a vague “AI cleanup” claim because it tells the analyst exactly which decisions remain theirs.

Observed Microsoft Marketplace evidence

Observation date: 2026-08-09. Three official Microsoft Marketplace listings were observed for closely related Excel cleanup jobs. Together they displayed 30 ratings. Ratings are a visible marketplace signal, not paid users, active installs, revenue, retention, conversion, or proof that this offer will sell. Direct command-line requests to the listing pages returned HTTP 403; the receipt preserves that limitation instead of pretending a response body was directly captured.

ComparableDisplayed ratingObserved position
AI Tools For Excel5.0 (2 ratings)Preview-before-apply cleanup, duplicate review, formatting, error repair, and free plus Pro plans
Change Case1.9 (16 ratings)One-purpose case normalization; listing warns formulas can be overwritten by values
Ablebits Text Toolkit4.6 (12 ratings)Text-cleanup toolkit distributed as an Excel add-in

AI Tools For Excel explicitly advertises preview-before-apply cleanup and duplicate review. Change Case demonstrates demand for a narrow normalization utility, while its listing also warns that formulas may be overwritten by values. Ablebits Text Toolkit is another Excel text-cleanup surface. These products show a crowded utility shelf, so “we clean spreadsheets” is not a wedge. The demand test here is the audit trail: a replayable per-sheet transform log, before-and-preview-after counts, unresolved values that stay unresolved, and zero silent writes.

Download the dated market probe and its official source URLs.

The marketplace gate has not been crossed

Microsoft's official publisher documentation says an Office add-in needs a Partner Center account, applicable Marketplace validation policies, approval, and certification before it appears in Microsoft Marketplace and within Office. Marketplace enrollment requires a company work account, verified business information, someone with authority to act for the company, and acceptance of the Microsoft Publisher Agreement. That acceptance is a contract. This run did not create an account or accept it.

The official certification policies also require predictable behavior. An add-in must not make unexpected changes to a document or launch external functionality without explicit permission. That is why the public test freezes a zero-write contract before any add-in exists. A future task pane would need a visible preview, an explicit apply step, a tested undo or reversal path, a privacy policy, clear data handling, and compatibility tests across every platform claimed by its manifest.

The publisher FAQ states that Marketplace charges no listing fee and applies a standard three-percent service fee to transactable offers. That does not make this pilot transactable. Microsoft documents Office add-ins as free to download when linked to a separately monetized SaaS offer. Designing that paid architecture, registering an application, accepting publisher terms, and submitting for certification all remain later gates. None is implied by a public request page.

Why the pilot starts outside the add-in

A marketplace build is the expensive way to discover that buyers wanted a different rule set. The pilot tests the acceptance contract first: which sheets matter, which types are declared, which comparison keys are safe, which values must remain unresolved, and what a Power BI handoff needs. An analyst can inspect the public schema before sharing a file. A serious request supplies the first real, authorized acceptance case; the synthetic receipt supplies a concrete format without processing customer data.

The pilot runs on a buyer-controlled export only after scope and file-handling terms are accepted. It returns a cleaned preview copy, never overwrites the original, and names every proposed change. Sensitive or regulated data is excluded unless a later, specific handling agreement permits it. The initial demand test asks only for a description of the workbook shape and decision problem. It does not ask for a file, link, Microsoft credential, tenant identifier, or Power BI workspace.

If no analyst requests this evidence-led scope, building the add-in would create software without buyer proof. If qualified analysts request it, the pilot receipts show which deterministic rules and review controls deserve to become product features. The marketplace then becomes a distribution and billing rail for an already-defined product, not a substitute for defining one.

Three steps from this test to an installable product

  1. Request and qualify one pilot. Tell us the workbook purpose, approximate sheet count, known cleanup problems, intended Excel platforms, and whether the cleaned preview feeds Power Query or Power BI. Do not upload a workbook, credentials, private link, or tenant information.
  2. Prove the review-only receipt. After a human accepts scope and file-handling terms, run the deterministic preview on an agreed non-sensitive fixture or export. Every proposed change must retain its source cell, original value, rule, confidence, and zero-write state.
  3. Build and seek distribution only after evidence. A future Office add-in must pass cross-platform manifest tests, privacy and security review, preview-and-apply controls, reversal tests, and Microsoft certification. A Power BI handoff must be tested separately and may remain a documented Power Query output rather than a custom visual.

Demand-test boundary: this page counts product-specific requests separately from reach. Our own probes, search crawlers, marketplace ratings, and page fetches are never buyer demand. A request is contact, not payment, a contract, an accepted file, a Marketplace approval, or permission to build.

Request the cleanup pilot scope

Questions an analyst should ask

Will this modify my workbook?

No. The proposed pilot returns a separate preview copy and transform log. The original is never overwritten. Every potential change stays reviewable, and unresolved values stay unresolved. A future add-in would need an explicit apply action and reversal tests before write mode could be considered.

Does duplicate detection delete rows?

No. It groups candidate rows under buyer-approved comparison keys and cites the source rows and fields that matched. The buyer decides whether the records represent the same entity or event. Candidate grouping is evidence for review, not authorization to merge or delete.

Does Power BI support mean you publish to our workspace?

No. The pilot's Power BI deliverable is a handoff note for the cleaned preview and its Power Query-ready columns. It does not connect to a tenant, refresh a dataset, publish a report, edit a semantic model, or claim that a custom visual exists.

Is the $249 price a subscription?

No. It is a proposed one-time founding-team price for one accepted workbook scope, one cleaned preview, one CSV transform log, and one HTML receipt. There is no automatic renewal. A future per-user subscription would be a separate offer with separate pricing and Microsoft Marketplace requirements.

Why not promise AI cleanup?

Because a broad model-generated rewrite can hide the exact rule that changed a business value. The pilot begins with deterministic, schema-bound transformations and explicit unknowns. A model may help classify internal candidate patterns later, but an unverified suggestion cannot become a workbook write or a customer-facing fact.