Case studies · Serviced accommodation
The best thing they owned was losing money
A property that looked like the strongest asset in the portfolio was losing money, and nothing in the reporting could show it.
A property that looked like the strongest asset in a seventeen-property portfolio was quietly running at a loss, and no report in the business could have shown it. A forensic audit found that roughly one pound in every five of recorded operating cost was reaching no property account. That is the size of the problem found, not money recovered: most of it turned out to be cost that needed classifying correctly rather than moving. Floodlight New Marketing built StayOps, a control layer above Hostaway, and corrected the part that genuinely belonged to one property back onto it, with evidence and a named approval behind every record.
For years, SLH believed one property was the best thing they owned.
The bookings backed it up. The revenue backed it up. Every report they had said the same thing. It showed a very small cost figure against its recorded revenue, and an apparent margin any operator would be pleased with.
It was losing money. It had been losing money for as long as the gap had existed, and there was no report in the business that could have told them.
Nobody at SLH did anything wrong. A Hostaway listing was deleted after an accidental removal and re-added under a new number, which happens, and years of cost history quietly came away from the property it belonged to. What made it dangerous is that the gap did not look like an error. It looked like their best asset.
Why nothing flagged it
Cost that is not attached to the thing that incurred it does not surface as a problem. It does not appear in red. It appears as nothing at all.
The money still left the bank. The invoice is still filed. It simply never reaches the report that decides what you keep, what you reprice and what you exit. Every total on that report is arithmetically correct. Every decision taken from it is not.
That is the quiet danger in this class of error. It does not announce itself, and it very often arrives disguised as good news.
SLH ran seventeen short-let properties on Hostaway, and their bookings were in good order. Several years of recorded revenue across more than a thousand confirmed bookings, all of it accurate. Hostaway did its job. The problem was history.
When a listing is deleted and replaced, everything recorded against the old one loses its connection to the property. The new listing starts clean. The old costs stay behind, attached to an identifier that no longer resolves to anything, in a report nobody can read.
That is not peculiar to one system. Anywhere an external identifier doubles as the identity of the thing itself, deleting it does not just lose a reference. It orphans everything that pointed at it, silently, and usually nobody finds out for years.
What was actually underneath
A forensic audit of the full expense export found roughly one pound in every five of recorded operating cost with no valid property attribution. It divided five ways, and that split is the most important thing in this case study.
- A deleted listing, traced to one property, carrying the largest single group
- A second deleted listing whose identity could not be documented
- Build costs on a property under development, which are capital and not operating cost
- Genuine company overhead that belongs to no single property
- Properties that were never listed on Hostaway at all
Only one of those five groups was a data problem with a clean answer. Build costs are capital and must stay out of operating cost. Overhead belongs to no property. The second deleted listing could not be documented and stayed blocked.
This is the part most tools get wrong, and it is worth sitting with. A tool that had simply emptied the queue would have pushed tens of thousands of pounds of build cost into operating expense. The dashboard would have looked better. The accounts would have been worse. Two thirds of what was found was not money to move at all.
That distinction is the whole difference between automation and control.
The defect that would have hidden everything
The most valuable finding of the engagement was a defect in our own software.
Recovering a deleted listing by creating a new property for it would have removed those costs from the investigation queue without ever adding them to the profit and loss account. The queue would have emptied. The dashboard would have gone green. Everything would have looked like success.
The report would have stayed exactly as wrong as it started, and the largest unresolved group would have quietly ceased to exist anywhere in the business.
We were one review away from building the same invisible error we had been brought in to find. It was caught by structured adversarial review before a single pound had moved, and fixed before production use.
This is the worst class of defect a financial system can carry, because it fails in the direction of looking correct. Every acceptance criterion would have passed. The client would have found it months later, in their own accounts, with no reason to suspect the tool that caused it.
What was built
StayOps sits above Hostaway as a control and reconciliation layer. It does not replace the property management system. Hostaway keeps the bookings. This is an integration, not a migration, and that distinction is the point.
An identity that outlives the listing
Every property carries a permanent internal identity that no external system controls. A Hostaway listing number is evidence about a property, not the property itself. When a listing is deleted and replaced, the old number becomes a historical identity attached to the permanent property, carrying its evidence document, the verifier and the timestamp.
Evidence before money moves
Historical cost can only be allocated where a document has been attached and verified by an authorised person. The database will not accept an identity marked as verified unless a verifier, a timestamp and an evidence document are all present, and that constraint holds even against direct database access.
A queue that cannot lie
Imported records are never modified. Decisions sit alongside them as an overlay, so the record and the decision stay separable. An expense counts as resolved only if its listing sits inside the same governed set the profit and loss account uses, so the queue cannot report a record as fixed while the accounts still treat it as orphaned.
Correction proved in both directions
Your team signs off before anything moves, on the exact records, count, currency and total. The correction then re-reads every record live from Hostaway and checks its listing, date, concept and amount against what was imported, aborting on any drift. It changes only the property link. Every other field is sent back exactly as found, then read back and compared. If any protected field returns different, the operation fails rather than reporting success.
A batch reads as fully reconciled only when the correction completed, the re-import succeeded and not one record is out of place. Anything less stays visibly incomplete with the outstanding count on screen. Nothing is changed on a machine's judgement, and every financial change carries a named human approval written to a trail the system refuses to update or delete.
What a small expense bought
The first record moved was a window-cleaning charge, one of the smallest single records in the whole export. Moving it exposed a behaviour in the Hostaway interface: an update containing only the property link can silently clear the expense's category.
The category was restored, independently read back, and the write path was changed to send and verify the complete set of protected fields on every subsequent write.
That behaviour was found on the smallest transaction available instead of on the largest mortgage batch. Deliberately testing the riskiest operation on the smallest possible transaction is not caution. It is the difference between a system you can point at your accounts and one you cannot.
The moment it proved itself
After the largest batch, every record in the import resolved into one of three states, and those states summed exactly to the population. The investigation queue fell by precisely the number of records that batch contained, measured against an earlier checkpoint taken before the correction ran.
Two independent counters, measured at different times, moving by exactly the amount the audit trail says was moved.
That is the moment a number becomes trustworthy again. Not because anyone says it is, but because two things that were never told what the other would say agree anyway.
What changed
A decision reversed. The property SLH would have backed is the one recorded at a loss. The one they might have exited was never the problem. Once its housing and operating costs were attached, its recorded net contribution was below zero. Whether that leads to a repricing, a renegotiation or an exit is SLH's decision. The point is that it is now a decision taken on real numbers.
History survived a deleted listing. Costs recorded against a retired listing stay attached to the permanent property. Replacing a listing no longer costs the business its trading record.
A larger exposure found and named. This property was not the only one reporting revenue against materially incomplete cost. The others are now surfaced in the investigation queue with their evidence requirements attached, rather than sitting undiscovered in a spreadsheet.
Time went back into the business. The manual searching, matching and rekeying that one operations role carried has largely gone. That is a person who spent their week keeping records straight, and now spends it growing the portfolio instead.
What is still open
A reconciliation report that claims everything is closed is a reconciliation report nobody should believe.
- Further historical records on the same property, each needing invoice or account evidence before it can be assigned
- Records with no Hostaway listing at all, including build costs that are being kept out of operating cost on purpose
- A second deleted listing whose identity is unproven, blocked until documentary evidence exists
These stay visible, each carrying its own value inside the system, until they are properly resolved. Open exceptions are worth more than a clean dashboard, because they are the part you can check.
This is not a finished project with a number at the end of it. StayOps is running in production at SLH now, and the remaining groups go through the same queue under the same evidence rule as the documents arrive to support them. That is the point of building it as a control layer rather than a one-off clean-up: the next correction works exactly like the last one, and leaves the same trail behind it.
The question this leaves you with
SLH's numbers were not the result of carelessness. Nobody was negligent. A listing was deleted and re-added, and the reporting quietly stopped being true. There was no report in existence that could have shown it, which means no amount of diligence would have caught it.
That is the uncomfortable part, and it is the part that travels. The question is not whether your data has drifted somewhere. Given enough years and enough system changes, it has.
The question is whether anything you own would tell you.
The domain changes and the shape does not. A customer record keyed on a supplier's account number. A project keyed on a tool's project ID. A cost centre keyed on a code a finance system can retire. Same exposure, same fix: hold your own permanent identity, gate every change behind evidence a person has signed off, and let nothing count as done until two systems agree.
You do not need to believe your reporting is broken to want that. You only need to have a number you cannot prove is right.
On the figures. This account is drawn from SLH's own Hostaway expense export and the StayOps audit trail between 24 July and 13 August 2026, and was checked against the running implementation rather than taken from documents. Exact sums are held back at the client's discretion. Where this piece describes the size of a problem found, that is what it means: cost that was not reaching a property account. It is not a statement that the same amount was recovered, and most of it was not money to move at all. Where it describes cost as corrected, it means corrected in the source system and read back field by field, not merely marked as resolved. The recorded net contribution is derived rather than read from a dashboard.
[Customer quote to be supplied and approved by SLH.]
Questions a similar operator asks
Does this replace the system we already run?
No. Hostaway keeps the bookings and remains the property management system. StayOps cannot create a property in Hostaway, and that is not a setting: the connector permits three kinds of request and a listing write is not one of them.
What happens to our data if we stop working with Floodlight New Marketing?
The corrections are written into your own system of record, so the corrected attribution stays there whatever happens next. The decision history and the audit trail belong to you and stay in your instance.
Is an AI assistant safe with our financial records?
No financial record is changed on a machine's judgement. Every change carries a named human approval against attached evidence, and the trail of who approved what, when, and against which document cannot be edited or deleted.
Could this work for a business that is not in serviced accommodation?
The domain changes and the shape does not. The pattern applies to any operations-heavy or data-heavy business where an external system's identifiers have been treated as identities. Being straight about it: this is one completed engagement plus a method, not a portfolio of sector proofs.
How long does something like this take?
This engagement ran from late July to mid August 2026. That is what it took here, on this data, at this scale. It is a record, not a commitment. The only fixed timescale we offer is the audit's ten working days.