Five aparthotels, two operating companies, a single set of accounts, and each owner's statement produced straight from the entries.

An aparthotel is an apartment rented like a hotel room: you stay a few nights or a few months, but it has a kitchen and a living room. The operator runs five in French-speaking Switzerland, with a sixth in preparation: whole buildings, not rooms.

These buildings don't belong to him. He operates them for owners, to whom he owes a statement: what the property brought in, what it cost, what is due to them.

And operations are split across two companies, brought together in a group that has a third one, which manages housing on behalf of others. Same people, same accounts to keep, three scopes.

Odoo already handled accounting and invoicing for the two operating companies. What was missing was at the other end of the chain: the document each owner expects.

This wasn't a convenience that could be postponed. The deadline was there, and the statements had to go out. A commitment to a building owner isn't negotiated against an IT project's schedule.

Beyond that, there was no way to compare the establishments with each other, or to read the group's figures without adding them up yourself. And supplier invoices were approved outside any workflow.

[How the statements were produced before, or whether they were, remains to be established with the client.]

A statements module was built on top of the accounting. Each aparthotel's data flows up, and the owner's statement is generated from the accounting entries, based on the relevant accounts. Nobody rebuilds it by hand.

Analytic accounts were set up within each company, making it possible to see what each establishment brings in compared with the others: information that company-level accounting doesn't provide.

And since the group's companies live on the same instance, management reads the figures for the whole or for any one entity, without switching tools.

The site presents the establishments and their apartments. It stops there: booking goes to the industry's own tools, which know how to keep a calendar and rates, and conversation with travellers stays in the operator's tool, simply embedded in the page.

It's a scope decision, not a technical limit. Building a booking engine into a showcase site means creating a second place where an apartment's occupancy is written, and two places always end up contradicting each other.

The design had been entrusted to a designer before we arrived. We built the site, not its look.

Supplier invoices arrive in large numbers, and it's rarely the CFO who ordered the service. The workflow put in place reverses the order: the manager who placed the order first confirms the service was actually delivered, and only then does payment go out. Documents are filed in the same place as the approval that goes with them.

Nothing spectacular about it. It's what prevents paying for a service nobody received.

Payroll is being set up. The website and the sales tracking tool are being connected, so that a request submitted on the site lands in tracking instead of an inbox.

And management wants to bring in what still lives on the side, staff scheduling in particular. Each building block arrives because the previous one proved useful.