Excel workbook audit
A fixed-price audit of the workbooks your business runs on — for the pricing models, quoting tools, and reports that have quietly become critical software — and the safe first step to fixing them.
Last updated:An Excel workbook audit is a fixed-scope analysis of business-critical spreadsheets: what the workbook actually does, how its logic and dependencies fit together, where it is fragile, and how exposed the business is if its builder leaves. Revenant Systems delivers a written report and a visual dependency map — at a fixed price agreed up front.
Who is an Excel workbook audit for?
The audit fits firms running critical operations on large, long-lived workbooks — pricing models, scheduling, quoting, financial reporting — which is common in construction, insurance, logistics, manufacturing, and finance. In every case the workbook has become an undocumented application: years of accumulated business logic that nobody fully understands any more.
- The person who built it is leaving or retiring
- The workbook is breaking, slow, or outgrown
- Replacement plans stall because nobody can describe what it does
- Audit or compliance questions (end-user computing risk)
Who is the audit not for?
A workbook one person can still explain in an afternoon probably doesn't need auditing, and a single broken formula is a quick piece of direct help rather than a fixed-scope engagement. The audit is built for large, long-lived workbooks whose logic has outgrown anyone's full understanding — and whose failure would hurt the business.
Can you fix a complex Excel spreadsheet?
Yes — and for a workbook the business depends on, the safe order is audit first, then repair. The audit maps the logic, dependencies, fragile formulas, external links, macros, and business rules before anything is changed, so a fix doesn't break the parts nobody knew existed. Some workbooks are then stabilised in Excel; others move to a replacement roadmap or a build-ready specification — the findings make that call with evidence.
- A quoting workbook of linked sheets and price tables, built up over years
- A finance model maintained by one senior employee
- A scheduling workbook fed by exports and manual copy-paste
What does the audit tell you?
The audit answers the question nobody in the firm can: what does this workbook actually do? It maps the full dependency structure, inventories the logic, separates repeated, templated calculations from genuine one-off exceptions, and flags fragile constructs, error-prone regions, and external links — along with where the key-person risk and documentation gaps sit.
The analysis is mechanical, not manual: the workbook's structure and logic are extracted programmatically and then interpreted by a senior engineer — faster and more thorough than a hand review, and not dependent on a reader spotting every link by eye.
- Full dependency structure, within and across sheets and workbooks
- Logic inventory: repeated patterns vs one-off exceptions
- Fragile constructs and error-prone regions
- External links and data feeds
- Key-person risk and documentation gaps
The dependency map
Every audit includes a visual map of the workbook's dependency structure — how sheets, formulas, and external sources actually connect. For most firms it is the first time anyone has seen the whole picture, and it tends to settle years of folklore about what feeds what.
Stage 2 — a replacement roadmap
The audit stands alone — but for firms considering a move off Excel, an optional second stage turns its findings into a sequenced recommendation: which components justify proper software, in what order, and whether to build or buy each one. Sometimes the honest answer is that a part is fine as a spreadsheet and should stay one. The advice is independent of any build work, so there is no incentive to recommend development you don't need.
Stage 3 — a build-ready specification
For the components you decide to replace, an optional third stage produces a detailed specification: the actual logic, data flows, inputs and outputs, and edge cases the new software must implement — derived from the analysis, not from memory. It is written so any competent development team, yours or a vendor of your choosing, can quote and build with far less risk and padding.
What is end-user computing risk?
End-user computing (EUC) risk is the regulatory term for business-critical logic living in tools built outside IT governance — most often spreadsheets. Regulators in financial services and other regulated sectors expect firms to know where those workbooks are, what they do, and how they are controlled. The audit provides exactly that evidence.
What you receive
- A written report: logic inventory, repeated patterns vs one-off exceptions, fragile regions, and external dependencies
- A visual dependency map of the workbook(s)
- A key-person-risk and documentation-gap assessment
- A findings walkthrough call
How the engagement runs
- Typical turnaround: two to three weeks from start to report
- Fixed scope and fixed price, agreed before work starts
What we need from you
- The workbook file or files, including linked workbooks where possible
- A note of the process the workbook runs and who relies on it
- A short walkthrough with whoever knows it best — while they are still available
Access and client data are handled under our information security statement.
Frequently asked questions
Can you fix the workbook itself, or only audit it?
Both — repair and stabilisation are available as separately scoped, fixed-price follow-on work: untangling fragile regions, fixing errors, and documenting as we go, once the audit has mapped what is safe to touch. Some workbooks should simply be made sound and stay in Excel; the audit is deliberately honest about which.
The person who built our spreadsheet is leaving — where do we start?
With the audit, promptly — while questions can still be asked. It maps the dependency structure and inventories the logic, turning knowledge that lives in one person's head into documentation the business owns. The report and dependency map are exactly the artefacts a successor, or a replacement build, needs.
Does the audit cover macros, VBA, Power Query, and linked workbooks?
Linked workbooks and external data feeds are core scope — the dependency map covers connections within and across workbooks, including the external sources a workbook quietly depends on. Where a workbook leans on VBA or Power Query, that logic is included in the inventory as part of understanding what the workbook actually does.
Do we have to replace the workbook?
No. The audit stands alone: a firm with no intention of replacing anything still gets documentation and a risk assessment it cannot easily get any other way. The later stages exist for firms that choose them — there is no obligation to continue.
Is each stage really fixed-price?
Yes — one agreed scope and one agreed price per stage, set before that stage starts. The audit is priced on its own; the roadmap and specification are scoped separately, so you only ever commit to the stage you are in.
Could our own developers build from the specification?
That is the point of it. The specification is written so any competent team — in-house or a vendor of your choosing — can quote and build from it. It does not tie you to Revenant Systems; implementation can be discussed case by case, but the document deliberately stands alone.
Each package is an audit or assessment offered on its own — the process behind it is covered in how we work.