← Blog

Causes of QoE Gaps: The Data Failures That Surface in Quality of Earnings

A QoE gap is the difference between the earnings you reported and the earnings the accounting firm can actually support. When that gap opens up, the buyer adjusts the number down. The deal gets repriced, or it slows while everyone chases the variance.

The accounting firms that run quality of earnings work are very good at finding those gaps. They are not in the business of explaining them. They flag the adjustment and move on. The diagnosis of why the gap exists in the first place is left to you, usually under time pressure, usually mid-deal.

I wrote before about why your QoE report will expose data problems before the buyer does. This piece goes one level deeper. It names the specific data failures that produce QoE gaps, because almost every one of them is a data problem wearing an accounting costume.

If you know the patterns, you can find them before the accountants do. That is the whole game. The same finding costs you nothing if you surface it in a pre-QoE audit and costs you multiple points of value if the buyer surfaces it in diligence.

Here are the failure patterns I see most often.

Pattern one: revenue recognition definitions that drifted

Most companies do not write down their revenue recognition policy and then follow it for ten years. The policy lives in practice, in how the controller actually books things, and practice drifts.

A new product gets sold on a different contract structure and someone makes a judgment call on when to recognize it. An acquisition brings its own recognition habits and they never get harmonized. A subscription tier changes and the cutoff logic does not change with it. None of these is fraud. Each one is a small, reasonable decision made without reference to a documented standard.

In a QoE this shows up as revenue that cannot be tied to a consistent rule. The accounting firm samples contracts, traces them to the recognized revenue, and finds that similar contracts were treated differently in different periods. Now they cannot trust the revenue trend, because the trend is partly a story about how recognition drifted rather than how the business grew.

Catch it by pulling a sample of contracts across the last three years and tracing each to how its revenue was recognized. If two similar deals were handled differently, you have drift. Write the policy down, apply it consistently, and document every deliberate exception with the reason.

Pattern two: billing-to-GL mismatches

This is the classic. Your billing system says one number. Your general ledger says another. The two were never designed to reconcile, or there is a manual step between them that quietly introduces error.

The systems are each internally consistent. Billing is correct for what billing does. The GL is correct for what the GL does. They just do not agree, because revenue gets summarized, reclassified, or adjusted on the way from one to the other, and nobody maintains a bridge that explains the difference.

In a QoE, the accounting firm asks for a reconciliation between billing and the GL. The controller pulls it together for the first time, live, and the numbers do not tie. Now the variance is the story. Every revenue assumption in the model is suspect until the gap is explained, and explaining it under deal pressure is expensive and slow.

Catch it by building a monthly reconciliation between billing and the GL before you ever go to market. Document the differences you expect, such as timing, recognition rules, and currency. Track the variance you cannot explain. A reconciliation that has run cleanly for twelve months is one of the strongest signals you can hand a buyer.

Pattern three: customer and SKU records that do not reconcile across systems

Your CRM has one customer list. Your billing system has another. Your GL allocates revenue across codes that map cleanly to neither. The same problem repeats at the product level, where SKUs in the catalog do not match the SKUs that actually carry revenue.

This happens because each system was built for a different job at a different time, and no master record sits above them. The CRM serves sales. Billing serves collections. The GL serves accounting. Each maintains its own version of who the customer is and what the product is.

In a QoE, this surfaces the moment the accounting firm tries to test revenue by customer or margin by product. The cuts do not agree. Customer concentration looks different depending on which system you start from. Product profitability cannot be verified because the product taxonomy is inconsistent. The buyer cannot build a clean view of where the money actually comes from, and concentration risk they cannot see clearly, they price conservatively.

Catch it by reconciling your customer master and your SKU master across systems. You do not need a perfect golden record. You need to know where the lists diverge and be able to explain it. This is the same discipline that underpins data governance that raises valuation, where the point of governance is not control for its own sake but a single trusted view of the things that drive the number.

Pattern four: cutoff and timing errors

Cutoff is about which period a transaction belongs to. Revenue booked in March that should have landed in April. An expense accrued late. A shipment recognized on order date in one quarter and delivery date in the next. Individually small. In aggregate, they move EBITDA.

Timing errors creep in through manual close processes, through systems that do not enforce period locks, and through the natural temptation to pull a good month forward or push a bad cost back. Most of it is not deliberate. It is the residue of a close process that runs on judgment instead of rules.

In a QoE, cutoff testing is standard. The accounting firm looks at transactions around period boundaries and checks whether they landed in the right period. When they find revenue pulled forward or costs deferred, two things happen. The specific periods get restated, and the firm starts to wonder how disciplined the whole close is. A cutoff finding is rarely just about the dollars. It is a confidence finding.

Catch it by testing your own period boundaries. Take the last several quarter-ends, pull the transactions in the days on either side, and check that each was recognized in the correct period under a consistent rule. Tighten the close so period assignment follows policy rather than preference.

Pattern five: manual spreadsheet adjustments with no lineage

EBITDA adjustments are expected in every QoE. The problem is not that you make them. The problem is when the support for each one is a spreadsheet that only one person understands, full of formulas that reference other spreadsheets, some of which have been renamed or moved.

This is how most mid-market companies build their adjusted EBITDA. Add-backs for owner expenses, one-time costs, pro forma effects of acquisitions, normalization for run rate. Each one is calculated in Excel, layered on top of the last, with the logic living in someone’s head and the audit trail living in a folder nobody else can navigate.

In a QoE, the accounting firm has to trace every adjustment back to source data. When the trail runs through five layers of linked workbooks, they spend your time and your money untangling it, and they finish with less confidence than they started. An adjustment they cannot trace is an adjustment they discount. A discounted add-back is a smaller adjusted EBITDA, which is a smaller multiple base.

Catch it by maintaining adjustment documentation in a structured form with a clear link from each adjustment back to source transactions. Every add-back should have a description, a dollar amount, the supporting evidence, and the person who approved it. The test is simple. Could someone who has never seen the adjustment follow it from the number to the source on their own?

The thread that runs through all five

These are five different patterns, but they share one root. Each is a place where the company cannot produce a single, traceable, consistent version of a number that matters. Definitions drifted. Systems disagree. Masters do not reconcile. Periods are loose. Adjustments have no lineage.

A QoE gap is what that looks like when a third party with a financial incentive goes looking. The accounting firm is not creating the problem. It is finding a problem that was already there, on the worst possible timeline, in front of the worst possible audience.

This is also why these failures rarely come alone. A company that lets revenue recognition drift usually has loose cutoff discipline too. A company with three customer masters usually supports its add-backs in undocumented spreadsheets. The same underlying habit, managing the numbers on conviction rather than on a traceable system of record, produces all of them. I wrote about how this same habit shows up across the business in the two integrity gaps that quietly drain portfolio value.

How to find these before the accountants do

You do not need an accounting firm to run this on yourself. You need someone who understands your systems to stress-test the joins between them, working through the five patterns above.

Pull a sample of contracts and trace revenue recognition for drift. Build the billing-to-GL reconciliation and see if it ties. Reconcile the customer and SKU masters across systems and find where they diverge. Test the transactions around your last few period-ends for cutoff. Trace every EBITDA adjustment from the number back to source.

This is a one-to-two-week exercise for a focused team. The output is not a clean bill of health. The output is a list of exactly where your QoE gaps will appear, ranked by dollar impact, with enough lead time to close the real ones and a prepared answer for the rest.

The worst outcome in a QoE is being surprised. Even when you cannot fix every gap before diligence, knowing it is there changes the conversation from “we did not know about this” to “we identified this, here is the impact, and here is the plan.” One of those reprices the deal. The other one does not.

The causes of QoE gaps are knowable in advance, because they are data failures and data failures leave a trail. Find the trail first.