Test the finance skill before it touches the workbook.

Finance skills have crossed from prompts into operating procedures

Microsoft announced on October 29 that Copilot now includes more than 25 finance skills and partner plugins across Excel and Cowork. The catalog spans account reconciliation, journal entries, reporting, audit, tax, FP&A, compliance, training, three-statement modeling, acquisition work, capital markets, ERP data, Fabric, and partner sources. The control question is no longer whether a chatbot can suggest a formula. It is whether a reusable skill can be trusted to operate on a particular financial work product.

The experiences are not one risk class. Finance skills in Copilot in Excel are generally available. New accounting capabilities are described as Frontier. Cowork finance and capital-markets plugins are generally available, while the Dynamics 365 ERP apps plugin and partner plugins have their own rollout states and prerequisites. A skill that reads a frozen workbook is different from a plugin that can query or write to an ERP environment.

Microsoft provides useful controls. Finance users can choose an optional audit trail for accounting capabilities. Copilot can use workbook change history, identify who changed what, explain effects, and selectively reverse edits. Microsoft says prompts and responses stay within the Microsoft 365 service boundary, permissions and sensitivity labels are honored, and customer content is not used to train foundation models.

Those controls answer important questions about traceability and service operation. They do not prove that a selected skill used the right source, applied the right accounting rule, preserved the right period, produced a balanced entry, kept formulas maintainable, or stopped before an unauthorized write. Microsoft Support separately warns that AI output can be inaccurate and advises against using Copilot to make sensitive decisions in areas such as finance.

The acceptance unit is smaller than the product

“Microsoft Copilot approved” is too broad to be an operating control. The same tenant can expose different skills, models, plugins, data sources, permissions, rollout rings, and write paths. Approval should name the exact combination that was tested.

Versioning may be imperfect when a vendor exposes a named skill without a customer-visible semantic version. Record the product release state, tenant/ring, model option, date/time, selected skill, plugin versions where available, workbook hash, prompt, and evidence digest. If Microsoft or a partner changes behavior, treat the old receipt as historical evidence, not perpetual approval.

Put the acceptance gate between capability and work product

approved user + exact skill passport
          |
          v
frozen workbook / source snapshot
          |
          v
Copilot in Excel or Cowork
  -> selected skill
  -> approved connector/plugin
  -> plan + proposed changes or actions
          |
          v
evidence capture
  -> prompt, audit/chat trail, tool calls
  -> before/after workbook and cell/formula diff
  -> source IDs, permissions, timestamps
          |
          v
deterministic reperformance + human challenge
          |
          v
exact-version release manifest or BLOCKED

Use a controlled copy for acceptance. Preserve the source workbook and test output separately. A before/after file comparison should inventory formulas, hardcodes, values, formatting, named ranges, hidden content, macros, links, connections, comments, and metadata. A visually correct model can still contain a hardcoded subtotal, a stale link, or a formula that excludes one row.

For Cowork and plugins, add an action ledger. Microsoft documents that the Dynamics 365 ERP apps plugin can perform write operations when asked and presents a summary before approval. That preview is necessary but not sufficient. Test role permissions, environment selection, transaction identity, duplicate requests, idempotency, partial failure, read-back, downstream triggers, and reversal.

A finance test pack needs more than happy-path accuracy

Define expected results before running the skill. Otherwise reviewers tend to accept a plausible output and rewrite the test around it. Seed at least one known failure in each material test family. A control that has never been observed turning red is not proven.

Worked example: accept check-model for an internal forecast review

The built-in check-model finance skill is described as checking circular references, broken formulas, hardcoded overrides, balance-sheet imbalances, cash-flow mismatches, and logic gaps. That is a useful bounded candidate. The team wants it to review an internal three-statement forecast before a human model review.

1. Freeze a clean approved workbook and create test copies with one defect each: a broken cash-flow link, a hardcoded EBITDA subtotal, an unbalanced balance sheet, a circularity, a stale external link, and a formula that omits a newly inserted row.
2. Record the exact Copilot tenant, skill selection, release state, model/configuration, user, workbook hashes, prompt, and time. Disable external connectors for the first test.
3. Run the skill on the clean workbook and each seeded copy. Preserve the plan, chat/audit trail, findings, and every proposed workbook change.
4. Compare findings to the defect manifest. False negatives on balance, cash flow, or hardcodes are blockers. False positives are classified by reviewer burden and risk.
5. Accept proposed fixes only in a review copy. Diff formulas, values, hardcodes, ranges, formats, names, links, and hidden content. Recalculate with Excel and tie the three statements independently.
6. Have a qualified reviewer inspect the packet without relying on the original chat. Ask them to locate each seeded defect, understand each change, reject an inappropriate fix, and restore the approved base.
7. Release only the review use case: internal model checking on controlled workbooks. Do not infer approval for model construction, valuation, external reporting, journal posting, or acquisition decisions.

This example complements the site's Finance spreadsheet review workflow. That workflow governs a workbook review. This page governs whether a reusable AI skill is permitted to participate in that review at all.

An audit trail explains activity; it does not approve the result

Microsoft's optional accounting audit trail can create a chat-history record of what Copilot changed and why. Workbook activity context can identify when changes were made and by whom, and selective reversal can undo individual edits. Preserve those records because they improve investigation and reviewer orientation.

Then add the evidence they do not guarantee: frozen input hash, exact selected skill, model/configuration, source identifiers, plugin calls, formula-level diff, deterministic calculation, tie-out, reviewer challenge, exceptions, exact release version, and distribution record. An explanation generated by the same model that made a change is useful context, not independent proof.

Selective reversal is also not a complete rollback plan. A workbook edit may already have fed a deck, report, approval, email, ERP upload, or downstream workbook. Rollback must include consequence discovery and correction. For write-capable plugins, preserve the system transaction ID, before/after record, read-back, downstream events, reversal authority, and corrected-state verification.

Failure modes to put in the acceptance plan

Run a 30-day acceptance sprint

Days 1-5: inventory available finance skills and plugins, their rollout states, users, environments, permissions, data sources, write paths, and owners. Select one reversible, read-oriented skill. Write allowed and prohibited uses.

Days 6-10: build the skill passport, frozen input set, deterministic oracle, defect-seeded copies, expected results, tolerances, evidence capture, and named review map. Do not start with production data or write authority.

Days 11-15: run golden, edge, formula, definition, lineage, permission, and adversarial cases. Preserve the audit trail and independent workbook diff. Reperform every material calculation.

Days 16-20: test repeatability, human review, selective reversal, full-file restore, downstream consequence discovery, access removal, and suspension. If the future use includes a plugin write, test it in a non-production environment with idempotency and read-back.

Days 21-25: remediate failures and rerun the same pack. Measure reviewer time, missed defects, false positives, overrides, unexplained changes, and correction effort. Compare with the current human process.

Days 26-30: hold the release decision. Approve one exact scope with expiry, monitoring, change triggers, suspension, evidence retention, and rollback. Broader skills, new plugins, new models, or higher-consequence outputs require their own acceptance.

FAQ

What is a finance AI skill acceptance test?

It is a controlled evaluation of one exact skill and use case against expected results, known failures, permissions, lineage, deterministic calculations, human review, monitoring, and rollback.

Is the optional Copilot audit trail enough?

No. It improves traceability, but Finance still needs a frozen source, independent diff, source lineage, deterministic reperformance, qualified review, exact-version approval, and consequence-aware rollback.

Can Cowork change ERP records?

Microsoft documents that the Dynamics 365 ERP apps plugin can perform writes when requested. Review the planned operation and test environment, permissions, identity, idempotency, read-back, downstream effects, and reversal before production use.

Should every finance skill be tested separately?

Group only when the skills share the same mechanism, data route, permission, consequence, and oracle. A model-checking skill and a journal-entry skill have different failure consequences and should not inherit one approval.

When does approval expire?

Set a fixed review date and retest after changes to the skill, model, prompt, plugin, connector, permissions, source schema, workbook template, policy, materiality, output class, or downstream use, and after incidents.