Use case: recovering the money you have already earned but not collected

The Río Sereno Hotel, fictional, used here only to illustrate, did not have a sales problem. Rooms filled up, guests checked in, reviews were good. And still, every month-end, the manager felt the same knot in her stomach: the numbers did not add up. Money was missing that, according to every record, someone should have paid. It was not theft. It was not a cash-drawer error. It was something quieter and far more common: revenue trapped in accounts receivable, money already earned but not yet collected, hidden in plain sight.

The symptom: mismatches and month-end surprises

It always started the same way. On the 28th or 29th of each month, someone on the team would put together the report for management. They added up what had come into the cash drawer, compared it against what operations claimed to have sold, and the subtraction never landed on zero. A piece was missing. Sometimes small, sometimes uncomfortably large.

The explanation always arrived late and always in fragments. A company that booked ten nights for its executives “would pay by transfer next week,” and that week had already come and gone twice. A wedding group that left a deposit and never settled the balance. A travel agency billed at thirty days that, with no one keeping count, was already at sixty. Each case, on its own, looked minor. Together, they were the knot in the stomach.

The expensive part was not the amount. It was the moment they found out: when so much time had passed that asking for the money felt awkward, and sometimes even pointless. Finding out late is, in practice, finding out lost.

The cause: bookings and payments live in separate tables

When they finally investigated, the root was always the same, and it had nothing to do with the team being careless. The problem was structural: the booking lived on one side and the payment on the other. Two tables that never looked each other in the eye.

The booking knew how much should be charged: so many nights, at such a rate, for such an amount. The payment knew how much had come in: this transfer, this card charge, this cash at the front desk. But nobody, anywhere, subtracted one from the other automatically and live. To know the balance of an account you had to open two screens, export two lists and cross them by hand in a spreadsheet. And that, naturally, got done once a month, when it was already too late.

Spider Data starts precisely from that fracture. It crosses eight operational sources, bookings, cash, channels, payments, guests, orders, shifts and cash movements, into a single structure. The two tables that never spoke stop being separate: now they can be placed side by side and subtracted.

A hotel rarely loses the money it is owed. It loses sight of it. And what you do not watch in time gets collected late, or never.A Spider Data principle

The solution: building the booking × payment cross

In the no-code report builder, drag and drop, everything in plain language, without writing a single line, the Río Sereno manager built something that used to take her a whole afternoon of spreadsheet work. She took the bookings table, the payments table, and joined them by the thing they share: the booking they belong to. That is a cross between tables, technically called a JOIN: stitching two lists together by a shared field so you can see them as one.

On top of that cross she created a new calculated field, a column the system works out on its own from other columns: the balance. The formula is the simplest thing in the world: what should have been charged minus what was already charged. If it comes to zero, the account is current. If it comes out positive, there is the money still outside, with a name attached.

Seeing it live, not last night’s close

The difference that changed everything was not the calculation, they could always do that by hand, but the timing. The Río Sereno dashboard shows balances live, not last night’s snapshot. If a transfer lands at eleven in the morning, at eleven in the morning the account shows settled. If a group leaves without paying, the balance is visible that same afternoon, not on the 29th of the following month.

With cross-filters, the manager could look at the same number from wherever she wanted: only corporate accounts, only agency accounts, only the ones open more than thirty days. One click on a filter, and the whole dashboard rearranged itself to tell that part of the story.

The alert that warns before, not after

The final step was to stop checking the dashboard on purpose. She scheduled an overdue-accounts alert: a rule that watches on its own and warns when a balance crosses a certain threshold of unpaid days. There was no longer anything to remember to review. The report arrived by itself, by scheduled delivery, every Monday first thing, with the accounts that needed a call that week, and only those.

The result: collecting in time, no longer finding out late

Let us put numbers on it, purely as an illustrative example, not real data from any hotel, so the mechanics are visible. Imagine that in any given month the Río Sereno had figures like the ones below spread across several accounts. Before, they were all discovered on the 29th, tangled in a single mismatch. Now each one has a face, an age and an owner from day one.

The change at Río Sereno was not charging more or selling more nights. It was no longer giving away, through forgetfulness, revenue it had already earned. Month-end stopped bringing surprises because nothing was hidden anymore: what was missing could be seen coming weeks in advance, while it was still easy and natural to ask for it.

How you would do it in your hotel

You do not need to be an analyst or know databases. If your operation is already on Spider Data, the path is short and you walk it in plain language:

1. Open the report builder and drag two tables into the same view: bookings and payments.
2. Join them by the booking they share, that is the cross that pairs what was owed with what came in.
3. Create a balance calculated field: amount to charge minus amount charged. Zero means current; positive means outstanding.
4. Turn the view into a live dashboard and add a filter by age (for example, “more than 30 days”).
5. Schedule an overdue-accounts alert so the system warns you on its own when a balance crosses your threshold.
6. Set up a scheduled delivery, Monday first thing, with the list of accounts that need a call that week.
7. If you like, take that same cross to Power BI, Tableau or Looker through the API with a token: your data does not live in a cage.

And if you would rather not build anything, you can simply ask in natural language: “which accounts have gone more than thirty days without paying?” The AI assembles the cross, summarizes it for you and, over time, flags patterns you had not even thought to look for, a client who always pays late, a channel that drags balances every season, and anomalies that fall outside the normal range.

The cheapest revenue to recover

There are many ways to improve a hotel’s finances: raise rates, fill low seasons, cut costs. Every one of them costs effort, risk, or both. Collecting what you are already owed costs none of that: the guest already stayed, the service was already given, the profit is already earned. It is simply on the other side of the counter, waiting for someone to look at it in time.

So it is worth saying plainly, less as a sales promise than as arithmetic: the revenue you have already earned but not collected is the cheapest to recover. It needs no new guest and no higher rate. It needs, barely, that you stop discovering it late, and that is exactly what changes when the booking and the payment finally look each other in the eye on the same screen.