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 £212,995.33 of recorded operating cost reaching no property account at all. 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 £2,558.00 of cost against £37,235.75 of revenue across 46 confirmed bookings, an apparent margin of about 93%.
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. £1,477,424 of recorded revenue across 1,392 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 £212,995.33 spread across 282 records with no valid property attribution. It divided five ways, and that split is the most important thing in this case study.
| Where it sat | Records | Value |
|---|---|---|
| A deleted listing, traced to one property | 121 | Not stated, see below |
| A second deleted listing, identity unproven | Not stated | Not stated, see below |
| Build costs on a property under development | 4 | £54,330.00 |
| Genuine company overhead | 13 | £5,169.60 |
| Properties never listed on Hostaway | 22 | £2,468.00 |
Two of those values are deliberately not quoted. The first group had a single allocation covering the whole of it prepared. An independent review blocked that allocation until three conditions were met, so the money moved instead as five smaller batches, each with its own evidence and its own approval. The second is a listing whose identity has never been documented, so it stays outside this account until it can be evidenced.
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 £54,330 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, a single line worth £60.00. 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 a 39-record mortgage batch worth £41,394.21. 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 mortgage batch, the expense import of 12 August 2026 returned 1,988 matched by listing, 130 reconciled in StayOps and 161 needing investigation, against 2,279 imported expenses. Those three states sum exactly to the population. An earlier checkpoint against the same import had shown 200 in the investigation queue. The fall from 200 to 161 is precisely the 39 records of the mortgage batch leaving the queue after the verified correction.
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 −£27,024.65. 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.
| Group | Records | Value | Position |
|---|---|---|---|
| Remaining historical records on the same property | 47 | £43,095.98 | Each needs invoice or account evidence before assignment |
| Records with no Hostaway listing, including build costs | 32 | £62,224.71 | Capital deliberately kept out of operating cost |
| A second deleted listing, identity unproven | Not stated | Not stated | Blocked until documentary evidence exists |
These stay visible, with their value attached, 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. Every number here is measured from SLH's own Hostaway expense export and the StayOps audit trail between 24 July and 13 August 2026, and checked against the running implementation rather than taken from documents. The £212,995.33 is the size of the problem found, not money recovered. Two figures are reported here and they are not interchangeable. £61,702.40 across 120 records was corrected in Hostaway and read back field by field. A smaller subset, 85 of those records, additionally completed the full chain through re-import and verification, and that subset is the stronger claim. The recorded net contribution is derived. Figures as at 13 August 2026.
[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.