Automated accounts processing for a Cyprus villa management group
A villa management company in Cyprus ended 2025 with more than 5,000 unprocessed invoices, late VAT returns, and a year-end bill above EUR 20,000. ZingZee built an accounting platform inside the system the company already ran, and one accounts manager now keeps the books.
Client A villa management company in Cyprus with hundreds of properties across the island and several companies in the group.
At a glance
One villa management group moved its accounting onto one platform and cleared a backlog that had occupied four people.
A villa management company in Cyprus with hundreds of properties across the island and several companies in the group.
A guest pays the company for a stay, usually by card at booking and sometimes by bank transfer nearer arrival, and most of that payment belongs to the owner of the villa.
The company's own income is its commission on the stay and an administration fee charged to the guest.
ZingZee was engaged to replace a manual, paper-driven accounting operation with an accounting platform built as custom code inside the company's own operating platform, with AI in the base, so that money is recorded at the point where it moves, whether that is a guest's card payment or a supplier's invoice.
The platform became the book of record in August 2026.
A backlog of more than 5,000 invoices was cleared in four days, the accounts team went from four people to one, and year-end accounting fees of more than EUR 20,000 went to zero.
Outcomes
5,000 unprocessed invoices cleared in four days.
Time per invoice down from up to 30 minutes to seconds.
Accounts team from four full-time staff to one accounts manager.
Year-end accounting fees from more than EUR 20,000 to zero, with the company producing its own accounts.
VAT returns and annual accounts filed on time, with no penalties.
Live P&L, balance sheet and cash flow, with drill-down from any figure to the receipt.
The challenge
At the end of 2025 the accounting ran on paper, in inboxes and in spreadsheets, and the team was always behind.
It works under three contract types: villas the company manages, which earn it the rent; villas it rents, which earn a margin; and owner villas it sells for a commission, with the balance owed to the owner. Each type moves money differently, so the accounting looks nothing like that of a normal business. HR, payroll, staff expenses and supplier payments were handled on paper, in inboxes and in spreadsheets.
Under Cyprus VAT rules the accommodation is taxed at the reduced rate of 9 percent while the company's fee is a service at the standard rate of 19 percent, so one guest payment needs two invoices: one raised on the owner's behalf for the stay and one from the company for its fee. The owner is paid after the stay, net of commission, with a statement showing each booking and each deduction. Card money reaches the bank days later, in batches, with the card provider's fees already taken off. An accounting system for this business has to keep the money it holds for owners apart from the money it has earned, from the moment both land in the same bank account.
The backlog
At the end of 2025 the company had more than 5,000 unprocessed invoices in boxes of paper, and nobody could say what had been paid or what was owed. Every invoice was keyed by hand, and one with several line items and more than one VAT rate took up to 30 minutes to enter. Whenever the auditor needed the records, the same data was pulled out and re-keyed into the auditor's system, so every invoice was typed at least twice into two sets of books that never agreed. One head of accounts and three bookkeepers worked on this full time and were always behind.
The owner side
The owner side of the business was in a worse state than the supplier side. Each owner statement was assembled by hand from the booking records and the bank statements, and the split between the owner's money and the company's commission was worked out in a spreadsheet for each booking. The two invoices behind every guest payment, the owner's at the reduced rate and the company's fee at the standard rate, were raised from templates and numbered by hand, so numbers were skipped, reused or never issued. When an owner queried a statement, the bookkeeper rebuilt it, and the rebuilt version rarely matched the first.
Card money
Card money was the third problem. The card provider paid out in batches every few days, each batch the sum of dozens of guest payments with fees and refunds already deducted, and the bookkeepers matched them to bookings by hand. Guests who paid in sterling were settled in euros at a rate nobody recorded. Deposits taken months before a stay were declared for VAT in the period of the stay, when the rules place the tax point at the moment the cash is received, so returns were wrong as well as late.
The consequences
The operation cost four people's time and more than EUR 20,000 a year to outside accountants, with penalties on top, and every decision was made on numbers months old.
- 01
Receipts were lost in pockets, gloveboxes and drawers, and supplier invoices never reached the office. Each one was VAT the company could not reclaim.
- 02
There was no chart of accounts, so spend was not coded to anything, budgets were never compared to actuals, and a rough spend breakdown took weeks or months.
- 03
There was no P&L, balance sheet or pivot. Month end, when it happened, was weeks late, and every decision was made on numbers months old.
- 04
With several group companies, suppliers invoiced the wrong one, and VAT was claimed by the wrong entity or by nobody.
- 05
The same invoice was sometimes paid twice from two companies, and recurring payments were missed one month and paid double the next.
- 06
Staff cards were spent daily and reconciled months later, if at all, leaving hundreds of card lines with no invoice behind them.
- 07
Owner statements were built by hand from booking records and bank statements, then argued over. Commission invoices were raised and numbered by hand, and sometimes not at all.
- 08
Owners were sometimes paid on bookings whose card payment had failed, because the booking record said paid and nobody checked the bank.
- 09
Damage deposits and refunds were tracked in a spreadsheet nobody trusted, and refunds went out late, twice, or not at all.
- 10
Every VAT return and every set of annual accounts was late, and fines were treated as a fixed annual cost.
- 11
Year end meant multiple audits to reconstruct the books, auditor queries answered from memory, and a bill of more than EUR 20,000.
The company was growing, and each new property added owners to pay and invoices to key, so the accounts team could not be scaled fast enough to keep up.
The group now produces its own accounts on the platform, and ZingZee continues to run and extend it.
5,000 unprocessed invoices cleared in four days.
The solution
An off-the-shelf accounting package would not fit the company's contracts.
ZingZee built the accounting platform as custom code inside the operating platform the company already ran. Initial work focused on input, because nothing else works if spend does not reach the system. The bank feed followed, then the accounting structure, then owner payouts, then the reports, and finally the AI consultant.
Getting money recorded
Spend capture from a phone
A staff app lets a member of staff pay, photograph the invoice and submit it from wherever the payment is made. A receipt now reaches the ledger on the day it is paid, and the company reclaims VAT on spend that used to be lost.
An AI invoice inbox
The inbox reads the photo or PDF, extracts the header, the line items and each VAT rate, codes every line to the chart of accounts, picks the right group company from the payee record and posts the invoice for a one-tap approval. A person checks the coded invoice, and every correction feeds back so the next invoice from that supplier is coded correctly first time. The accounts manager now approves a day's invoices in the time one invoice used to take to key.
A native bank feed with card and transfer matching
Every card payment and transfer lands in the ledger as it happens and is matched to its invoice or booking automatically. Card settlement batches are broken back into the guest payments they contain, with the provider's fees and any currency difference posted to their own accounts. A card line with no invoice is flagged to the person who spent it, the platform alerts if the feed drops, and matching refuses to pair the same invoice twice. The bank and the ledger now agree every morning, and the company knows how much guest money it holds on any given day.
A cash ledger as the source of collected money
A booking shows as collected only for the sum of the bank lines matched to it, and every downstream process reads that figure rather than the booking record's paid field. An owner cannot be paid on a booking whose money has not arrived, and VAT on a deposit is declared in the period the cash was received.
Chart of accounts, budgets and VAT
The chart carries a budget on every code and VAT on every line, converts spend to euros, and runs a due-date engine with a calendar of paid and unpaid items. Cyprus VAT rules are built in: tax point at cash receipt, kept deposits taxable, the reduced rate on accommodation and the standard rate on the company's fees. The VAT return is now built from the ledger in minutes, and budget against actual is visible on every code without a report being prepared.
Payees with validation and invoice numbering from the database
Every payee is tied to the right group company and VAT treatment, so an invoice cannot be raised or paid in the wrong name. An invoice generator with its own PDF engine issues company invoices, and each number is taken from a sequence held in the database at the moment the invoice is posted, so numbers cannot be skipped or duplicated. The auditor's first question at year end, whether the invoice run is complete, is answered by the numbering itself.
Recurring payments
Recurring payments are held as first-class records, so scheduled money goes out once, on time. The double payments and missed months stopped in the first cycle after cutover.
Paying owners and seeing the numbers
A commission engine and owner payouts
The engine prices each night of a stay on its own, so a booking that crosses a rate change is split correctly between the owner's money and the company's commission. Each guest payment produces two documents: an invoice for the accommodation raised on the owner's behalf at the reduced rate, and the company's administration-fee invoice at the standard rate. Payout reports are built from money-backed bookings, one hold per payout, with the owner's statement PDF attached and the commission invoice raised automatically at final payout. Guest money and owner money are shown separately in every drill-down, and historic reports can be regenerated with a dry run first. Owner statements now go out on schedule, and an owner's query is answered by opening the drill-down.
A refunds pipeline
The pipeline runs through five stages with their own automations, from requested to sent to reconciled against the bank line. A refund cannot be sent twice, and the company can see at any time how much it owes guests.
Live reporting
Reporting covers P&L, balance sheet and cash flow with forecasting on the same data, drill-down from any figure to the receipt photo, and a pivot that ties out to the chart of accounts at zero delta. Month close takes seconds, and the directors read the month's position on the first day of the next one.
Payroll and leave
Payroll, annual leave and sick leave run through the staff app. The accounts manager no longer chases managers for hours at month end.
An AI finance consultant
Staff ask the platform, by voice, what is missing, what does not add up and what has changed since last month. A question that used to wait for the accounts manager's free afternoon is answered on the spot.
Access is by name only: three people and one finance agent can open the platform.
What was hard
Three problems took longer than the rest of the build, and each one changed the design.
- 01
Card payouts that arrive netted, batched and late.
The card provider paid the company in batches, each covering several days of guest payments, with its fees and any refunds deducted before the money was sent. A bank line of a few thousand euros corresponded to nothing in the bookings, and guests who paid in sterling had been converted at the provider's rate on the settlement day. Our first matcher worked on amounts alone and failed on almost every batch. We rebuilt it to import the provider's settlement report alongside the bank line, match the batch by settlement reference and date, break it into the payments it contained, and match each of those to a booking by its payment reference. Fees and currency differences post to their own accounts, and a batch closes only when its parts add up to the bank line to the cent.
- 02
A ledger rebuilt from years of exports.
The old records were a collection of exports rather than a set of books: payables with line items, bank statements from several accounts, a payee list in which the same supplier appeared under four spellings, and invoices entered into two group companies at once. The migration canonicalised every payee, removed duplicate invoices on the combination of payee, number and amount, matched bank lines to invoices wherever a match could be proved, and parked the rest in a suspense account. Opening balances were agreed to the last audited accounts before a single new transaction was posted. The migration ran as a dry run several times until the pivot tied out to the chart of accounts at zero delta, and only then was the old system frozen.
- 03
Deciding what paid means.
The booking system's paid field turned out to mean several things: a card authorisation had succeeded, an agent had ticked a box, or a transfer had been promised. The bank records showed a different position, with card holds that had expired, transfers short by bank charges and refunds that had reversed part of a payment. Owner payouts and VAT returns both read that field. We made the cash ledger the only source of collected money and had every process read the sum of matched bank lines instead. The change exposed bookings marked paid with no money behind them and money in the bank with no booking against it, and each case was resolved with the accounts manager before payouts could run. A booking is now recorded as collected only when matched bank lines confirm the money.
How it was delivered
- Phase by phaseZingZee delivered the platform in phases, in the order the business needed them, and each phase went into daily use as soon as it was finished. Spend capture and the AI inbox came first, so that new invoices stopped joining the backlog while the rest was built.
- The teamTwo ZingZee engineers and a lead who had worked in finance ran the build, with the client's accounts manager as the daily counterpart, and her corrections in the inbox during the early weeks became the training data for the coding model.
- Before cutoverThe platform ran in parallel with the old records for one month-end close, and the two were reconciled line by line.
- August 2026On the cutover day the platform became the book of record and the old system was frozen.
- The next four daysThe invoice backlog was submitted through the staff app over the following four days.
The results
The group runs its accounting on one platform with one accounts manager, where it previously had a head of accounts and three bookkeepers who were always behind.
What runs itself
- Spend capture.
- Bank matching.
- Settlement matching.
- Payout reports.
- Refunds.
- Recurring payments.
- Month close.
- Payroll.
- The alerts for a dropped feed or an unmatched card line.
All of these now run without the accounts team's involvement.
What's next
Forecasting will extend further out, with cash flow, balance sheet and P&L projected from the live pipeline of bookings. More of the auditor's work will be done by the platform, so that sign-off takes less of the auditor's time. The same platform can run the accounting for another operator with the same contract shapes.
