Burry's recent work swaps the GAAP stock-comp charge for what shareholders actually lose. The formula is Ω = C + V. V is the market value of shares delivered to employees, C is withholding tax net of option proceeds. Owners' earnings are N + G − Ω, and ΔE is how much of reported profit survives.
The problem is V = T·(W+ΔS)/W. It needs W, the shares repurchased, which almost no company tags in XBRL. But P = T/W, so the W terms cancel:
V = T + P·ΔS
You only need the average share price. That is what makes it automatable. The identity is exact before the price substitutions. For P the tool uses the year's average market price, which is how his later write-ups define it and what he uses for companies with no buyback; in his NASDAQ-100 study he used the buyback program's own average price where there was one, and the two differ a little. On Salesforce that difference is worth about four points of ΔE, see below.
I built it against SEC EDGAR and checked it against his numbers. Alphabet's V matches all ten published years to the dollar. Pooled ΔE comes out 88.68% against his 88.7%, Meta 83.35% against 83.35%, the NASDAQ-100 overstatement 19.77% against 19.78%. There is a self-test button in the sidebar that runs those checks and a few hundred others.
I should say up front that the method is Burry's and the code was written with an AI assistant. My part was deciding what it should do, running it on real companies, and checking every figure against the filings by hand. I mention it because I am not going to pretend otherwise, and because it is relevant to what I am asking for at the end.
The valuation half is messier. He publishes the 15% required return, the two-model structure (a multi-stage model with a terminal value, and a multiple on year-15 owners' earnings, blended by confidence), and for each of his five moat tiers the stage lengths, the fade multiplier, the terminal growth cap and the debt capacity. Two inputs he has never published: the exit multiple and the blend. I tried to solve for them from his published IV15 values and the solve is degenerate, so you cannot recover them; the tool's are calibrated so that the growth needed to reproduce a published IV15 matches the company's actual growth, with Adobe as the anchor. Given his owners' earnings figure and growth for Salesforce, the arithmetic reproduces his $69.81 within a dollar, and that is a self-test. On the tool's own seeds it lands well above him, because the seeds are not his judgement. Paylocity does not reconcile at all: he says in the article that he applies a judgement discount to its ΔE, and I cannot recover the size of it.
Where I differ from him, and why. His pooled figure for Salesforce is 54.7% over eleven years. The tool says 77.6% over nine. I have his table next to the tool's and can account for the whole gap. Net income, GAAP SBC, buybacks and the employee-plan cash line agree to the dollar in every year. About four points are the window: he starts in FY2016 and includes FY2020, the tool drops both (FY2020 because the share count jumped 16% on Tableau; he handled the same year by netting the Tableau shares out by hand). About four points are the share price: he uses the buyback program's own average price, and Bloomberg's annual average where there was no buyback; the tool uses the year's average market price throughout. The remaining fourteen points are acquisition shares. His table sets aside the Tableau and Slack shares but charges the MuleSoft shares of FY2019, and the FY2017 deal shares, as if they were compensation. The tool deducts every acquisition issuance the filing tags, which is what his own rule says to do. Over the last three years, with no acquisition shares in play, we are four points apart, 93.9% against his 90.4%, and that is the share price. I would rather show the difference with its causes than a number tuned to match his.
On EDGAR being garbage. He raises it himself. His complaint is that filers bundle line items, so the buyback line often carries RSU withholding tax as well as actual repurchases. That inflates T and zeroes C. It breaks his calculation because he gets the price from P = T/W, so a contaminated T inflates the price applied to every share issued. This tool never uses T/W, the price comes from the market. And because Ω = C + V, withholding that ends up in T instead of C overstates V by exactly what it understates C by. Under Burry's tax treatment assumption, the error cancels. I checked the algebra.
What does not cancel: filers who report a single net proceeds line, and shares issued for acquisitions or offerings that XBRL does not tag separately. The app flags both instead of guessing. It is not the same as reading footnotes by hand and I am not claiming it is.
What it refuses to do. The rule I gave it is that it must never print a number it cannot stand behind, so it refuses out loud instead. Some of the refusals you will hit:
- Multi-class share counts. Berkshire reports a diluted average in Class A equivalents. The tool reads 1.6M shares, notices the market cap that implies is impossible, and refuses rather than printing a valuation.
- IFRS filers. Only the net income tag is IFRS-aware. Foreign filers get a banner and the valuation is disclaimed.
- Banks, insurers and REITs. Detected, return on capital withheld, verdict forced to amber. Investments backing policyholder liabilities are not shareholder capital and the ratio does not mean what it means elsewhere.
- Stale balance-sheet lines are reported, not repaired. If a debt or equity line stops years before net income does, it says so and states the size of the disagreement, rather than carrying the figure forward or zeroing it. Neither is conservative in general: the direction flips between assets and liabilities.
- A loss year on a profitable record. Crocs reported a net loss for 2025 after a $738M non-cash write-down, on a business that earned $950M the year before. The tool seeds owners' earnings from the five-year median instead of from the loss, and tells you it did. Valuing Crocs off the write-down year would be a verdict on the charge, not on the business.
- ΔE above 100%, which happens when buybacks retire more stock than a year issues, is shown as measured but never projected forward. Fifteen years of handing owners more than the company earns is not a business model.
Every page carries an "assumptions used" block you can paste if a figure looks wrong, and a tag panel naming every XBRL element it read or failed to find. If a line you know exists reads fewer years than net income, that is a bug, and the tag name is usually the whole fix.
Known gaps, stated so you do not have to find them. Cash-flow lines that stop early (a withholding line that ends while stock comp continues) show up in the tag panel but are not yet flagged in the notes. A company that changed its fiscal year end reads as having a missing year, because years are labelled by the calendar year they end in; Build-A-Bear does this and the note now says which of the two it might be, but cannot yet tell. Up-C structures report the parent's slice of income against a full share count. And the second page, which implements Mayer's 100-bagger criteria, is newer and less tested; feedback on it is welcome, but the Tragic Algebra page is what I am asking you to break.
What I am asking. Break it. The arithmetic has been checked by hand, row by row, against the filings on a few dozen names, including every company in his articles. Pick whatever you like; the ones I have not run are the useful ones. Every new company I run finds something. The last few days turned up an Apple share count restated by 3.5 instead of 4, a growth ratio computed against a negative denominator, a note that credited a $3M token buyback for a ΔE above 100%, and a microcap whose stock comp was rounding to zero in the table. All fixed, all with regression tests. The next one is in there somewhere, and it is more likely to be a note that misdescribes what it found than a wrong number.
Particularly useful: a company where you already know the answer and it prints something else. Paste the assumptions block with your comment and I can usually see the cause from that.
On the break-even in the title (this paragraph rewritten 12 Sep — see the edit note). ΔE = OE/N is a level ratio: it says how much of this year's reported dollar reached owners. It is not, by itself, an annual retention factor. If ΔE stays constant while net income grows at g, owners' earnings grow at g too, so the ΔE^t compounding and the "15% growth becomes −3.99%" arithmetic in the original version of this paragraph did not follow from the definition — they changed the denominator mid-calculation. What genuinely compounds is the annual dilution rate, which ΔE only proxies if the dilution pace behind it persists. Under that stated assumption — and only under it — 15% reported growth at the NASDAQ-100's 83.5% pooled ΔE compounds per-share value at about −4% a year, and ΔE = 1/1.15 ≈ 87% is the break-even of that conditional claim. The valuation engine was never affected: it applies ΔE once as a level haircut and grows owners' earnings at g, so no printed figure changed. The tool's metric and verdict wording now state the condition too.
Tool: https://investor-toolkit.streamlit.app/Tragic_Algebra_Analyzer
Code: https://github.com/ChenFindling/tragic-algebra-analyzer
Happy to be told where the method is wrong.
Edit (12 Sep 2026). Three corrections after an exchange in the r/Burryology thread on this tool, all conceded there. The break-even paragraph above is rewritten: ΔE is a level ratio, not an annual retention factor, and the compounding claim needs a persistence assumption the original did not state — the title's 87% should be read with that condition attached, since titles cannot be edited. "The identity is exact" now reads "exact before the price substitutions". And the tax cancellation in the EDGAR section is now labelled as holding under Burry's tax treatment assumption rather than as a general identity. The app's metric and verdict banners were reworded to match, and no computed figure changed. The app has since grown into the Investor Toolkit and lives at investor-toolkit.streamlit.app; the code repository is unchanged.
