Accuracy: Why shepi Beats a Human in Excel
A spreadsheet trusts whoever typed last. shepi doesn't.
Every Quality of Earnings built by hand in Excel carries the same hidden tax: the human typing it. Numbers get retyped between source documents and the model. Formulas drift when rows get inserted. Sign conventions flip silently between tabs. None of these are exotic failures — they are the normal cost of doing financial analysis in a tool that has no idea what any cell is supposed to mean.
shepi removes that cost not by promising the impossible ("error-free analysis"), but by removing the steps where humans introduce errors in the first place: data entry, formula maintenance, and reconciling the same number across multiple outputs.
The Argument, In One Sentence
No retyping. No broken formulas. Same math, every time. The math in shepi is deterministic — given the same inputs, the engine produces the same outputs on every run. The data flowing into that engine isn't hand-keyed by an analyst at 1 a.m. It's parsed from source documents into a structured ledger. The outputs — workbook, PDF, dashboards — all read from that same ledger. There is no copy/paste step where a number can quietly become a different number.
The Human-Error Surface in a Manual QoE
Decades of spreadsheet research (Panko and others) put the rate of material errors in complex, hand-built workbooks alarmingly high. The categories below are not a hypothetical list — they are what every analyst who has built a QoE in Excel has debugged at 11 p.m. on a Sunday.
Re-keyed numbers
Trial balance values typed (or pasted as values) into a model. A single transposition or trailing zero quietly changes EBITDA.
Inserted-row formula drift
Adding a row to a category breaks SUM ranges further down the sheet. The total still looks reasonable, but it's wrong.
Sign convention flips
Revenue positive in one tab, expenses positive in another, adjustments inconsistently signed. The bridge ties out only by accident.
Tab-to-tab copy/paste
Adjustments live on one sheet, the bridge on another, the report on a third. Updating one and forgetting another is the default state.
Broken external references
Links to a closed workbook return #REF!. Links to an open workbook silently return last-saved values.
Period misalignment
TTM ending June compared to a fiscal year ending December, columns shifted one over, prior-period balances pulled from the wrong tab.
Hand-keyed bank tie-outs
Proof of cash done by reading PDFs and typing into a reconciliation grid. Every number is a chance to be wrong.
Versioning chaos
"QoE_final_v4_REVISED_JB_edits_USE_THIS_ONE.xlsx" — and three different people are working from three different files.
What shepi Removes — Structurally
These aren't "best practices" we ask users to follow. They are removed by the way the platform is built. You cannot accidentally re-type a number into shepi because there is no cell to type it into.
Source documents → parsed ledger
Trial balances, GLs, and supporting docs are parsed into a structured ledger. There is no human-data-entry step between the source PDF and the model.
One canonical chart-of-accounts mapping
Every account is mapped once. Adjustments, bridges, ratios, and the report all read the same mapping. Change it in one place, every output updates.
Deterministic adjustment engine
Given the same inputs, the math produces the same answer on every run. No floating cell references, no formula drift, no "works on my machine."
Single source of truth
The workbook, PDF report, and dashboards are not separate files in different states. They render from the same underlying data.
Full audit trail on every number
Every adjustment carries who entered it, when, what source it traces to, and the formula behind the computed value.
Period alignment is automatic
TTM, fiscal year, calendar year, and prior periods are computed from the same dated ledger. You don't shift columns by hand.
Failure Mode Comparison
| Failure Mode | Excel / Manual | shepi |
|---|---|---|
| Re-keyed source numbers | Constant risk on every project | Removed — data parsed from source |
| Broken SUM ranges after inserts | Common, hard to catch | Not possible — no hand-built ranges |
| Sign convention drift across tabs | Common | Removed — one signed ledger |
| Bridge doesn't tie to report | Frequent late-stage discovery | Removed — both read same data |
| Stale numbers in PDF vs. workbook | Default state until manually synced | Removed — single source |
| Audit trail for an individual number | Manual — if anyone bothered | Built in — every adjustment traced |
| Math reproducibility on re-run | Depends on cell state | Deterministic |
Where Humans Still Belong
Removing data-entry error is not the same as removing judgment. shepi does not, and should not, decide which one-time legal fee qualifies as an add-back, how aggressively to normalize owner compensation, or whether a customer concentration risk warrants a disclosed adjustment versus a footnote. Those are judgment calls, and they belong to a human.
That is exactly where the DFY tier sits: a matched, licensed CPA reviews the adjustments and the judgments behind them — on top of a deterministic engine that handles the math. Human-in-the-loop is not a hedge here; it's the right division of labor. Computers do the mechanical work without errors. People do the judgment work with accountability.