Same Metric, Different Quarter: The Comparability Checks Behind a Peer Median

A peer median is only as good as the assumption that every number in it describes the same thing. Most diligence workflows never test that assumption. A spreadsheet pulls "revenue" for ten companies, takes the middle value, and the result goes into a memo with a decimal point of false precision.

The trouble is that "revenue" is not one thing across ten filings. This post covers the checks LacunaIndex runs on a peer group before it will show a confident verdict, and what happens to a company that fails them.

Three ways identical labels hide different facts

LacunaIndex reads structured financial data from the filings companies submit to the U.S. Securities and Exchange Commission, tagged in a machine-readable format called XBRL (eXtensible Business Reporting Language). Before a peer group's figures are compared, a comparability guard looks at the same metric, for the same period, across every company in the group, and reports each way the group is not like-for-like.

1. The calendar problem

Not every company's fiscal year ends in December. A company whose quarter closes in September sits next to peers whose quarter closes in December, and a naive lookup lines them up as if they were the same quarter. They are not: the figures are three months apart, and in a fast-moving sector three months can be a large gap.

The guard searches a window of roughly three months (93 days) on either side of the target period. If a company has no figure for the exact period but does have one inside that window, it is flagged as a calendar mismatch rather than as missing data. The distinction matters. "We have nothing for this company" and "we have something, but it describes a different quarter" call for different responses from an analyst.

A calendar mismatch is raised as a warning, not a block. The guard tells you the comparison is imperfect and names the affected companies and their nearest reported period, so you can decide whether the gap matters for your thesis.

2. The currency problem

Filers report in the currency of their financial statements. If one company in a group reports in Australian dollars and the rest in U.S. dollars, a median of revenue across the group mixes units. The result is not a slightly noisy number; it is a category error.

For money-denominated metrics (revenue, net income, total assets, operating cash flow), the guard identifies the majority reporting currency and flags every company that reports in a different one. This is a block, not a warning. Without currency conversion, those companies cannot be compared, and the guard does not pretend otherwise.

3. The segment problem

A single filing can contain several revenue figures for the same period: one for the whole company and others for individual business segments. A careless query can grab whichever it sees first, or add segment figures together and compare the result with a peer's consolidated total.

The guard checks whether each company has at least one consolidated figure (one with no segment breakdown attached) for the period. If a company has only segment-level facts, it is flagged as a block, and the system falls back to a secondary data vendor rather than summing segments itself. Summing segments is exactly the kind of quiet guess that produces a plausible-looking wrong number.

Two smaller checks that still earn their place

Two further axes are raised as informational notes. The first is mixed accounting standards: most U.S. filers report under U.S. standards, while some foreign companies use the international standard, and the guard notes when a group mixes the two (as a warning, since absolute values are not directly comparable without adjustment). The second is restatements: if a company has more than one filing for the same period, the latest value is used, and the earlier values stay in the audit trail. A related note records when the figures in a group were ingested under different versions of the internal list that maps filing tags to metrics.

What happens to a company that fails

The guard's output is not just a report; it changes what the product will say. At the sector level, the guard runs on revenue (chosen because nearly every company reports it, so it exercises all the checks). Any company with a blocking issue is dropped from that sector's median, and the full list of caveats is stored alongside the result.

Two design choices stand out for diligence readers:

• No coverage is not "clean." If a sector has no structured filing data at all, the median is labeled unverified instead of passing silently. The same applies to a sector the guard has never evaluated: confident verdicts are suppressed until the first check completes.
• Read failures fail closed. If the system cannot read the stored verdict for a sector, it treats the sector as unverified rather than assuming everything is fine.

What to ask of any peer median

Whether or not you use LacunaIndex, the same questions apply to any comparison table in a diligence file:

1. Does every company's figure cover the same period, or did a different fiscal year-end slip in?
2. Is every figure in the same currency?
3. Is every figure consolidated, or did a segment number get mixed in?
4. Were any figures restated, and which version are you looking at?
5. If data was missing for some companies, does the table say so, or does the median quietly shrink?

A comparison that cannot answer these is a comparison of labels, not of businesses.