Process documentation when your process lives in Excel

Document an Excel-based process by treating the workbook as evidence, not as the document. Pull out the inputs, the transformations, the checks and the outputs. Then interview or observe the person who runs it, because the rules they apply that are not written in any cell are the part that matters.

The pattern is common. The process is not described anywhere. The process is the file.

Why is an Excel-based process so hard to document?

Because the file does the work and hides how.

Take a month-end close workbook at a mid-sized services firm. Eleven tabs. Tab four pulls from an export that somebody drops in a shared drive folder on the third business day. Tab six has a macro, written in 2016 by a contractor, that nobody has opened since. Column R is hidden. Three people know not to touch column R. Nobody can say why, only that the last time somebody did, the accruals were off by a number that took two days to find.

None of that is on a page. A new hire given the workbook sees a spreadsheet. A senior analyst sees a procedure with fourteen steps and four traps.

It gets worse in the inbox. The "current" version is whichever one the last person emailed. There are three of them, with names like Close_v7_FINAL_jm_edits. Which one is real depends on who you ask.

Then there is the part that was never in the file at all. Somebody opens the prior month's tab, eyeballs it against this month's, and says "that looks right." That is a control. It is also nowhere.

What should you extract from a workbook?

Five things. Skip the rest.

Inputs. Where does the data come from, who sends it, and when? Name the source system, the export, the person. "The AP export" is not an input. "The AP aging export from NetSuite, saved by the AP clerk to the Close folder by 5pm on business day three" is.

Transformations. What happens between input and output? Walk the formulas, but describe them in business terms. Not =VLOOKUP(B2,Map!A:C,3,0). Write "each vendor is mapped to a cost centre using the Map tab; vendors missing from the map return an error and must be added by hand."

Hardcodes and overrides. Every typed-over number is a decision somebody made. Find them. Most workbooks have a handful, and they are where the risk lives.

Checks. The cells that should sum to zero. The tab that compares to the ledger. The conditional format that turns red. These are your controls, and your auditor will want them.

Outputs. What leaves the workbook, in what form, to whom? A PDF to the controller. A pasted range into a board deck. An upload to the ERP.

That is a procedure. It is not complete yet, but it is a skeleton you can check against reality.

If you have a few hundred of these workbooks across a shared services centre, doing this by hand is a year of work. Zipper Blueprint for Operations is being built to read the workbooks, the email threads that move them around and the Confluence or SharePoint pages that half-describe them, then draft a procedure for a person to confirm.

How do you document the parts that only exist as habit?

Watch the work. Do not ask for a description.

A walkthrough described from memory might have six steps while the recorded work contains eleven. The missing five are usually habits the expert no longer notices: sort by date before filtering, delete the blank row at the bottom of the export, check that the total row was not included, rename the tab, save a copy first.

Ask a person to describe work and you get the version they would tell a stranger. Ask them to do it with you watching and you get the real one.

So run the process once, live, with screen share and a recording. Ask only two questions while it runs.

"Why did you do that?" gets you the reason behind each step.

"What would go wrong if you skipped that?" gets you the control.

Column R falls out of this quickly. Somebody says "oh, I never touch that, it feeds the accrual on the summary tab," and now it is written down. Somebody else says "actually it feeds two things." Now you have found a disagreement, which is worth more than the documentation.

The macro is the same. Do not read it. Ask what the person expects it to do, run it, and compare. If nobody can say what it does, you have just learned that your close depends on a program no one understands. Write that down as a finding, not as a step.

Also capture the exceptions. "Except in March, when we also do the audit tie-out." "Except if the Singapore entity is late, in which case we run it twice." Exceptions are where a new person gets hurt.

What does good look like?

Short, checkable and findable.

A good document for a workbook-driven process has a one-paragraph purpose, the five extracted elements above, a named owner and a named backup, and the date it was last confirmed against reality. That last one matters most. A procedure confirmed last quarter is a procedure you can lean on. One confirmed in 2021 is fiction.

Test it the only way that counts. Hand it to someone who has never run the process and watch them try. Where they stop, the document is missing something. Fix it. Repeat once.

It should live where people already look. If your team lives in SharePoint, it goes in SharePoint. If it is Confluence, Confluence. A perfect document in a tool nobody opens is the same as no document. If it is a Smartsheet workflow, link to the sheet and describe what the columns mean.

And it should say where it came from. For audit purposes, whether SOC 2 or ISO 27001, "documented from the working file and a recorded walkthrough on this date" is a far stronger statement than "written by a manager from memory."

One practical note. These workbooks contain real numbers: payroll, client fees, margin. If you point any tool at them, including ours, ask where the files are processed and what is retained. I wrote that checklist up in AI documentation tools: what to check before you give one your repo. It is framed around code, but the seven questions apply to a finance share just as well.

Frequently asked

Should we replace the spreadsheet instead of documenting it? Maybe eventually. Document it first. You cannot replace a process you cannot describe, and the documentation is the requirements list for whatever replaces it. Teams that skip this step rebuild the same traps in a new tool.

What do we do about macros nobody understands? Do not try to read them first. Record what goes in and what comes out, run them against a known month and compare. Log the macro as a risk with an owner. Rewriting it is a separate project and usually a small one once the behaviour is pinned down.

How often should we re-confirm the document? Quarterly for anything tied to a close or a regulated deliverable, and any time the person running it changes. A new person running it is the best free test you will ever get. Have them mark up whatever was wrong.