# Sequential invoices and daily reconciliation for a villa operator

2026-11-07 · Carbon Media Solutions

What one operator's finance team asked for when bookings moved online — gapless numbering, invoices at check-out, an immutable archive and a day that balances — and how the booking platform was configured to answer it.

Most booking websites stop at "payment successful". The finance team's work starts there. Every stay has to become a numbered document, every rand has to be matched to a booking, and at the end of each day the money in the gateway, the folios in the property-management system and the ledger have to agree. When they don't, somebody spends the morning finding out why.

When we built a direct-booking platform for a villa operator, the finance team's requirements were the most precise part of the brief. What follows is how that platform was configured for them. It is one operator's approved set-up, agreed with their accountants, not general guidance; the tax questions in it are theirs to answer, and the platform is built so that the answers are settings rather than code.

## Numbers that cannot skip or repeat

The operator required a gapless invoice sequence — a missing number is a question an auditor will ask. Database sequences do not give you that, because a failed transaction burns a number. So numbering is issued inside the same transaction as the document, from a counter scoped to the legal entity, the document type and the year, resetting at the start of each year on the business's own clock. Test and live documents draw from separate scopes, so a test run can never consume a real number.

The second property is idempotency. A retry caused by a timeout must return the same invoice, not a second one. The system keys every issuance on the booking and the document's content, so an identical retry replays and a different request under the same key is refused.

## For this operator, the invoice is issued at check-out

Their accountants' position was that a booking produces a confirmation, not an invoice; that a deposit is held as exactly that; and that the invoice is issued once, at check-out, from the folio as it stands then, with every extra on it — the chef, the late check-out, the additional night. Corrections are made in the property-management system before that moment, so the pipeline reads a corrected folio rather than editing documents after the fact.

When a tax invoice must be issued is set by the tax authority relative to the supply, and how deposits are treated depends on the entity's registration and its accountants' reading of its circumstances. The platform does not decide any of that. The moment of issue, the document type and the tax treatment are configured per legal entity, and the system refuses to issue a tax line it has not been explicitly configured to compute.

## Immutable, archived, traceable to a person

Once issued, a document never changes. The PDF is rendered once, stored with a content hash, and kept in storage that cannot be overwritten for at least the retention period the operator's accountants specify — retention rules are expressed relative to the returns the records support, so the period is a per-entity setting rather than a number in the code. A mistake is corrected by a credit note that references the original and is capped at its open value, never by editing. The reception team can pull the document for a guest; they cannot alter it. And every action that touches money or documents — issuing, voiding, releasing a held night, re-allocating a deposit — carries the name of the person who did it and the time.

That last requirement is not bureaucracy. The fraud a finance team worries about is quiet re-allocation: an old deposit moved onto a new booking so it reads as paid, and the cash leaving the building. A record of every movement, with a per-person daily cash-up that must balance the next day, is the control.

## A day that balances

Reconciliation has three legs: what the gateway settled, what the folios say, and what the ledger holds. The platform pulls the gateway's settlement feed automatically, matches each payment to its booking, and closes the day on a next-day basis once settlement is known, because card fees are only final at settlement. Anything that does not match is not forced; it is flagged for a person, with the reason. A day that does not prove out is held, not posted.

The output finance wanted was a single daily journal they could review and release, with revenue split per property and the control accounts common, rather than a stream of documents from the booking system duplicating what their accounting software already did.

## Why this belongs in the website project

None of this is visible to a guest, and all of it decides whether the operator trusts the direct channel. A booking engine that cannot produce the documents the finance team requires, or a balanced day, is a marketing tool the finance team routes around. If you are commissioning a booking platform, ask to see the invoice, the credit note and the day-end report before you ask to see the homepage — and bring your accountant to that conversation, because the settings are theirs.

## Frequently asked

### Why not let the property-management system issue invoices?

Because in this case its documents did not meet the operator's requirements: a gapless sequence per legal entity, immutability after issue, and credit notes tied to the original. The platform issues the document, and the PMS stays the source of the folio.

### What happens if a payment arrives that matches nothing?

It is recorded as unmatched money and shown to a person, with the amount and the gateway reference. Nothing is auto-assigned and nothing is quietly dropped.

### How long are documents kept?

For at least the retention period the operator's accountants set for those records. Retention requirements are defined relative to the returns the records support, so the platform treats the period as a per-entity setting rather than a fixed number.