Financial Ratios That Actually Predict Trouble (And the Ones That Lie to You)

Every ratio guide on the internet lists the same dozen metrics in the same flat order, as if current ratio and days sales outstanding are the same kind of number. They are not. One is arithmetic on figures that are already settled. The other depends on a definitional choice someone has to make before the calculation can even start. Treat them the same way and you get a dashboard that looks rigorous and quietly isn’t.

This distinction matters more once AI enters the picture. An AI computing a mechanical ratio from reconciled actuals will get it right every time, because there is only one right answer. An AI computing a judgment-dependent ratio without knowing which judgment call it inherited will produce a number that is internally consistent and still wrong for your business. The fix is not a better model. It is knowing which category each ratio falls into before you let anything, human or machine, report it.

Category one: ratios that are pure arithmetic

Some ratios take numbers that are already fixed by the ledger and divide them. There is no interpretation step. If the inputs are correct, the ratio is correct, full stop.

Ratio	Formula	What it tells you
Current ratio	Current assets ÷ current liabilities	Can you cover near-term obligations with near-term assets
Quick ratio	(Current assets − inventory) ÷ current liabilities	Same question, minus the least liquid asset
Gross margin	(Revenue − COGS) ÷ revenue	What’s left after the direct cost of delivering the product
Debt-to-equity	Total liabilities ÷ shareholders’ equity	How much of the balance sheet is financed by debt

These are the ratios worth automating first, because automating them is genuinely low-risk. A liquidity ratio computed off a reconciled balance sheet has nowhere to hide an error: the numerator and denominator are both already-closed figures. If the underlying accounts tie to the ledger, the ratio ties to reality. This is exactly the kind of calculation a deterministic engine should own outright, with an AI layer reading the result rather than deriving it fresh each time someone asks.

The catch is upstream, not in the ratio itself. If your “current liabilities” line includes a misclassified long-term note, or your inventory figure is stale because nobody ran a count this month, the ratio is arithmetically perfect and substantively wrong. Mechanical ratios are only as trustworthy as the reconciliation underneath them, which is the whole argument for closing the books before you trust anything computed on top.

Category two: ratios with a judgment call baked into the definition

The second category looks the same on a dashboard, a clean percentage or a small number, but the formula contains a decision that changes the answer depending on who’s making it.

Days Sales Outstanding (DSO) is the clearest example. The formula is simple: accounts receivable ÷ (revenue ÷ days in period). But “accounts receivable” is not one number. Do you include invoices under dispute? Receivables from a related entity? A customer that’s 200 days late and probably never paying: do you keep it in the denominator’s spirit, or write it off first and recompute? Two finance teams looking at the identical ledger can produce DSO figures eight or ten days apart, both defensible, both wrong to compare against each other without knowing the rule each one used.

Burn multiple has the same problem one layer deeper. The standard definition is net burn ÷ net new ARR, but “net burn” depends on what counts as growth spend versus baseline operating cost. A company that reclassifies a chunk of sales headcount as “growth investment” reports a better burn multiple than an identical company that doesn’t: same cash out the door, different label. The burn multiple glossary entry covers the mechanics; the point here is narrower: the number is only comparable across time, or across companies, if the classification rule stays fixed.

Cash conversion cycle stacks three judgment calls on top of each other: DSO, days inventory outstanding, and days payable outstanding all carry their own definitional ambiguity, then get summed. Get one input’s rule wrong and the cash conversion cycle shifts by a week or more without anything in the underlying business actually changing.

None of this makes these ratios useless. It makes them dangerous to trust blind, and specifically dangerous to hand to an AI without pinning the definition first.

Why this split matters more once AI is doing the computing

Ask a model “what’s our DSO” and it will answer. It has to pick a receivables definition to do the arithmetic, and unless that definition is fixed somewhere it can retrieve, it will pick one implicitly, probably whatever standard formula it saw most often in training, applied to whatever “accounts receivable” balance it finds first. That may not be your company’s convention. It may not even be the convention your finance team used last quarter, if the definition drifted and nobody wrote it down.

This is a narrower version of a problem covered elsewhere on this site: an LLM doing arithmetic in its own head is a probabilistic process wired into a spot that’s supposed to be deterministic. For mechanical ratios, that risk is contained, because the “logic” is just division, hard to get wrong once the inputs are locked. For judgment-dependent ratios, the risk compounds, because the model has to silently choose a business rule before it even starts computing. Two runs of the same question can legitimately differ if the underlying receivables filter isn’t pinned.

The practical fix is the same one that applies to every number an AI reports in finance: definitions get pinned once, upstream, in the model the AI queries, not re-derived per question. If “current” receivables excludes anything over 90 days and disputed invoices, that rule lives in the reconciled model, and every DSO calculation, whether run by a human or an assistant, inherits the same rule. The AI’s job becomes retrieving a number that was computed consistently, not deciding on the fly what “current” means today.

A quick sorting test for any ratio on your dashboard

Before trusting a ratio, or trusting an AI’s answer about it, ask two questions:

1. Are both inputs already fixed by the ledger, with no filtering or classification choice required to compute them? If yes, it’s mechanical. Treat deviations as real signal.
2. If two competent analysts pulled this ratio independently, could they land materially apart using different, equally reasonable definitions? If yes, it’s judgment-dependent. The ratio is only useful once the definition is written down and applied consistently, and any AI reporting it needs to cite which definition it used, not just the number.

Most published ratio guides skip this test entirely and present all twelve metrics with the same confident formatting. That’s fine for a glossary. It’s a liability on a live dashboard someone is using to decide whether to extend a customer’s terms or cut a department’s budget.

The takeaway

Not every ratio deserves the same level of trust, and the difference has nothing to do with how important the ratio is: burn multiple matters enormously to a board and is still built on a soft definition. What determines trust is whether the formula’s inputs are already settled by the ledger or require a classification call first. Mechanical ratios are safe to automate outright once the books are reconciled. Judgment-dependent ratios need their definitions pinned and disclosed before any number gets reported, by a person or a model.

If you’re evaluating how an AI vendor handles this, ask them directly: when your assistant reports DSO or burn multiple, does it show which definition it used, or just the number? Rexfin pins these definitions in the reconciled model itself, so every ratio, mechanical or judgment-dependent, traces back to a rule you can inspect. Book a demo to see it against your own chart of accounts.

For more on why the underlying model needs to be settled before any ratio gets computed on top of it, see KPI variance analysis, which covers the same reconciliation dependency from the reporting side.