From the PMS to the accounting system: what moves at day end and how to check it

At day end the hotel operating system (PMS) hands the accounting system a closed business day: revenue by department, the taxes inside it, payments by method, city ledger movements and deposits. The two systems are joined by an export file, a scheduled transfer or a direct connection, and the numbers are tied back by reconciliation, not by trust.

Every morning someone exports a file from the hotel system, uploads it into the accounting program, and hopes the totals agree. When they do not, the search starts in the wrong place: in the file, rather than in the rule that produced it. This guide covers the whole PMS accounting integration path: what should cross at day end, how revenue codes land in the chart of accounts, why corrections must travel as reversals, and how to reconcile the two systems daily and monthly. By the end you will be able to write the rules down, test them, and prove the numbers to anyone who asks.

Why do the PMS and the accounting system drift apart?#

They drift because they answer different questions. The PMS records what happened at the property during a business day; the accounting system records what the business owes, owns and must report, under rules the PMS does not enforce.

Start by defining both sides once. The PMS, or property management system, is the hotel operating system that runs reservations, the front desk, housekeeping and billing. The general ledger is the book of accounts the accountant posts to, organised by the chart of accounts. Neither system is wrong; they simply measure different things.

The two also keep different time. The PMS works in business days closed by night audit; the ledger works in fiscal periods. A charge posted at 00:30 belongs to one business day and lands in one fiscal period, and the boundary between them must be written down, not assumed. For the mechanics of closing the day in order, see the night audit checklist for closing the business day.

Detail is lost on the way across, and that is where errors hide. The PMS carries room numbers, guest names, outlets, waiter IDs and check numbers; the ledger carries accounts. Somewhere between the two, that operational detail is collapsed into totals and codes. If the collapse rule is not written, every rare charge becomes a small surprise.

The join is usually a person: an export, an upload, sometimes a spreadsheet in between. A manual step is not a defect by itself, but an undocumented manual step is. The most common source of drift is a correction made after the transfer: the PMS is fixed, the ledger is not, and the gap grows quietly until month end.

Before choosing any tool, write down the direction of truth. Which system is the record of what happened, and which is the record of what is reported? In most hotels the answer is that the PMS records events and the ledger reports them, and every later decision follows from that sentence.

What should cross at day end?#

Five groups cross: revenue by department, the taxes inside that revenue, payments by method, city ledger movements, and deposits and advances. Anything else is either detail the ledger does not need or a decision the accountant must make.

Revenue by department means rooms, food and beverage outlets, spa, minibar, laundry and other income, each as its own line, so the ledger can post to its own account. Taxes means the tax component separated from the revenue it sits on, so the ledger receives a net revenue figure and a tax liability figure rather than one mixed number. Payments by method means cash, card by acquirer, bank transfer, agency virtual card and foreign currency, each with its own total, so the bank and POS reconciliations have something to match.

City ledger movements are charges moved to a company or agency account, payments received against those accounts, and the closing balance per account; the city ledger deserves its own treatment, covered in hotel city ledger explained. Deposits and advances are money taken before arrival, money applied to a stay, and money still held, kept distinct from revenue until it is earned.

Some things are excluded on purpose: guest names, room numbers, folio line detail and staff names. The ledger needs totals and account codes, not the operational record. Keeping personal detail out of the transfer also keeps the accounting side out of scope for most guest data questions.

One rule prevents most arguments: the day-end file must be reproducible. Re-running the same closed business day must produce the same totals, every time. If it does not, the transfer is an opinion, not a record.

How do revenue codes map to the chart of accounts?#

Through a mapping register: a written list that says which PMS revenue code posts to which account in the chart of accounts, who owns the list, and when it was last reviewed. Without it, the mapping lives in one person's memory and leaves with them.

Start from the PMS side. List every revenue code and payment type the property can actually produce, including the rarely used ones: a late checkout fee, a lost key charge, a minibar restock. The rare codes are the ones that break month end, because nobody has decided where they belong.

Map many codes to one account where the ledger does not need the split. Use one-to-many only when a single charge must be divided, for example a package rate split between room and breakfast. Give every code a default account and a named owner. A code with no default account should block the transfer rather than post silently to a suspense account.

Version the register with dates. When the accountant changes an account, the change is recorded, so a later comparison of two months knows which mapping was in force in each. Review the register on a fixed rhythm: at minimum whenever a new outlet opens, a new payment method appears, or the chart of accounts changes.

Test the register once with a deliberately awkward day: a package rate, a split charge, a refund and a currency difference. If the mapping survives that, it will survive a normal Tuesday.

Why must corrections travel as reversals, never edits?#

Because a posted entry is a record of what was believed at a point in time. Editing it destroys the evidence of the error; a reversal plus a new entry keeps both the mistake and the correction visible to anyone who looks later.

The mechanism is simple. The original entry stays, a reversing entry cancels it, and a corrected entry replaces it. The net effect is right, and the history is intact. This applies on both sides: a charge voided in the PMS after the transfer must reach the ledger as a reversal, not as a quietly reduced total in the next file. The same discipline covers a folio that was closed, an invoice that was cancelled, and a payment applied to the wrong account.

The one action that cannot be reversed is a message already sent to a guest. Everything else should be undoable, and the reversal is how the accounting side sees the undo. For the operational side of this, see how to void a folio charge without breaking the audit trail.

A practical test: if someone asks why a number changed between two monthly reports, the answer should be a document, not a recollection. Agree the reversal window with the accountant: how many days back a correction may travel as a reversal in the current period, and when it must go into the next one.

Our hotel operating system is built on the same principle, ahead of launch: financial records are never deleted, corrections are voided and reversed, and night audit closes the business day.

What does the daily and monthly reconciliation check?#

It compares the same five groups in both systems and explains every difference. Daily checks catch today's mistake; the monthly check proves the period, and it is the one an auditor will ask for.

Daily, compare revenue by department, PMS total against ledger total, with the difference explained line by line rather than netted away. Compare payments by method against the POS and bank records, so a card batch that settled differently is found the next morning, not at month end. Compare the city ledger closing balance per account against the ledger's receivables, and deposits held against the deposits account.

Monthly, compare the sum of the daily transfers against the ledger period movement, which catches a day that was transferred twice or not at all. Produce an aged list of open city ledger accounts and unapplied deposits, and have a person review it, not just print it. Keep the evidence: the exported file, the transfer log and the signed reconciliation for each period, so the check can be repeated by someone else. And assign the sign-off: a reconciliation nobody signs is a report, not a control.

Which join should you choose: file export, scheduled transfer or direct connection?#

Choose the simplest join that your team can operate and check every day. A well-documented file export beats a direct connection nobody monitors, and the choice is about control and evidence, not about modernity.

Ask three questions of any option. Can it be re-run for a closed day? Can a failure be seen the same morning? Can an outsider follow what happened from the records alone? A scheduled transfer that hides failures is worse than a manual export that surfaces them, because the failure mode of an automated join is silence. The same logic applies to any connection a hotel runs, as with how a channel manager connection works: messages can be delayed or lost, and the design must make that visible.

Whatever the option, keep the day-end totals in a place both sides can read, so the reconciliation does not depend on one system's screen. And change one thing at a time: run a new join in parallel with the old one for a full period before switching, and compare the two outputs.

What stays with the accountant?#

Tax treatment, document timing and the accounting judgement on any charge stay with the accountant and the legal adviser. The software moves numbers faithfully; it does not decide what is owed.

Rates and duties are the first example. Which rate applies to accommodation, to food and beverage, to a package, and how a discount changes the base: confirm all of this with your accountant. No tax rate belongs in a software configuration decision made at the front desk. Document timing is the second: when an invoice or e-document must be issued, and what happens when a stay spans a period boundary, is a compliance question, not a PMS setting. For the Turkish specifics, see e-Fatura vs e-Arşiv: invoicing guests and agencies in Türkiye.

Deductibility and classification follow the same rule: whether a charge is revenue, a recovery or a write-off, and which account it belongs to, is an accounting decision. Currency too: the PMS may hold an exchange rate, but which rate applies on which date, and who records the difference, is decided in the accounting policy.

The boundary in one sentence: the PMS is responsible for the completeness and reproducibility of what it exports, and the accountant is responsible for what is done with it.

What to do next#

Write the mapping register first, then run one full month with the new join in parallel with the old one and reconcile both against the ledger before you switch. The parts of this guide fit in that order: the five groups define what must cross, the register defines where it lands, reversals keep the history honest, and the reconciliation is the proof that all three worked.

If you want to see how a hotel operating system can be designed around this discipline from the start, you can request a briefing at https://ai-otel.com/contact.