I kept running into one spreadsheet edge case in automation workflows: writing a formula-looking value is easy; proving the calculated value before the next workflow step is the hard part.
I put together a small n8n workflow for that boundary. It uses only built-in nodes:
The route writes one input cell in a demo forecast workbook, recalculates formulas, reads the computed output, exports/restores the workbook JSON, and returns checks like:
a workflow needs a quote, forecast, approval, or budget number
the next node needs calculated readback, not just a written cell
an AI/agent workflow needs workbook-like calculation state it can verify
Not useful for:
making Convert to File reinterpret a plain text cell as a formula
editing a live Excel Online / OneDrive workbook through the Microsoft Excel 365 node
preserving every XLSX formatting/chart feature
The point is not to replace Excel or Google Sheets. This is a no-install proof for the case where n8n owns the workbook-like calculation step and needs to verify the computed result before continuing.
Clever use of the verification round-trip — the checks.formulasPersisted and computedOutputChanged fields are a nice way to confirm the calculation actually ran rather than returning a cached or stale value.
For cases where adding an external HTTP dependency isn’t ideal, formulajs (available in n8n’s Code node) can evaluate common spreadsheet formula strings directly in-workflow — no API call needed. Might be worth exploring for the verification logic if you want to keep the pipeline fully self-contained. Welcome to the community!
hi @gregkonush welcome to the n8n community!
My only caveat is that the actual recalculation and verification happen in a Bilig app route, with the importable workflow defaulting to the hosted demo endpoint, so it’s not purely an in-n8n/local calculation path. For production use, I’d still evaluate data privacy, vendor dependency, and whether the calculation engine matches Excel/Google Sheets closely enough for approval or financial workflows.
I added a self-hosted workflow file so this doesn’t have to call the public demo endpoint:
The new import is `bilig-workpaper-formula-readback.self-hosted.n8n.json`. It points at `http://host.docker.internal:4321` first and falls back to `http://localhost:4321`, so n8n calls a Bilig app route you run yourself. It still uses only built-in n8n nodes; the final Code node returns `verified-local` and includes the data-boundary note.
Also agree on `formulajs`: for a scalar formula in one Code node, that is simpler. I would use this Bilig path only when the shape matters: cell addresses, stored formulas, recalculation, export/restore, and readback proof before the next node. And yes, for approval/finance workflows I would test the actual workbook formulas before relying on it.
Small update: there is now an installable community node for the same proof path.
Install in Settings → Community nodes:
`@bilig/n8n-nodes-workpaper`
It wraps the forecast readback route from this thread as a normal node, so you can test formula write → recalc → before/after/readback without wiring the HTTP Request node by hand. It still has no credentials and the README calls out the same limits: use the hosted demo for evaluation, or point the base URL at a Bilig app you run yourself for private data.
Source and README are in `proompteng/bilig` under `integrations/n8n-nodes-workpaper`.