Introduction to the Apaleo Accounting

The topics in this guide are also covered in a free, on-demand course in our Apaleo Community.

Already a member of the Apaleo Community? Find the course here.

Not yet in the Community? Follow these steps:

• Log in to your Apaleo account with your email.
• Click on this link.
• Select the option “Continue with your Apaleo profile”.
• Complete your Community profile to gain full access.

Key facts
The accounting schema
Description of accounts and specifics
Revenue Accounts
8000 Vat on Revenue
Payment Accounts
Receivables
Liabilities and 8001 Vat on Prepayment
City Taxes
Transitory Items
Understanding transactions
Business transactions and accounting transactions
Net vs gross
Posting vs business date
Retrieving data
Essentials for accountants
Last but not at all least - Please read me :-)

Key facts

Apaleo is doing double-entry accounting, and it's doing that in real-time. That means, whenever a transaction happens, it is immediately captured in Apaleo's accounting as an entry in at least two accounts as a debit and a credit. Apaleo knows single and composite records.

Apaleo’s accounting scheme is inspired by usali. Accounts are static in terms of codes and names. However, you can break down the revenue accounts to accommodate your business and reporting needs by using the sub-account structure. The mapping of Apaleo accounts to your main ledger is done outside Apaleo.

Apaleo is returning revenue and related entries – it is agnostic to expenses. You are not able to run petty cash with cash-in and cash-outs. You are not able to record any commissions for credit card payments, distribution channels, travel agencies etc.

You specify on rate plans, services, policies and distribution which VAT rate should be applied. It is critical that you pay attention to a proper set-up, and also on changes afterwards. Apaleo itself does not run a validation, i.e. is a VAT rate for a specific service in line with local VAT regulations.

Apaleo posts your prior business date revenues via the automated night audit, each night separately for each reservation – not all at check-in or all at check-out. Of course, Apaleo allows to manually or directly post charges. The latter are always posted to the business day on which they are recorded. You can't post those to previous business days.

Apaleo has a unique way to deal with prepayments (aka deposits, liabilities): Apaleo qualifies automatically if a payment should be treated as a prepayment – taking into account VAT – and also consumes prepayments based on a certain rule set. The consumption is done after each transaction. There is no (manual) transfer of a deposit to guest ledger at check-in for instance.

The entity which carries the transactions is either a reservation, an external folio or the house account. So actually, each entity is like a little trial balance having receivables, charges, VAT, payments and potentially prepayments and the consumption of those. The summary of the transactions of those entities for a selected period returns the accounts and amounts for your main ledger. It is up to you which level of detail you reflect in your main ledger.

A transaction recorded is locked immediately and you cannot modify it anymore, i.e. alter a specific entry. If you need to correct it, the correction is a new transaction, recorded the moment it is posted. Same applies for invoices: you have an initial, a cancellation and a correction invoice – all with a different invoice number.

And finally, in case you need to check something, Apaleo has log files on reservations and folios, and a view button on each reservation to look up the accounting transactions.

The accounting schema

The basic schema is provided by Apaleo out of the box - no need to spend time and thoughts on this. You can see it and navigate through it in Finance and Accounting. 

This basic schema is static on the top-level, and also for revenues and payment on the 2nd level. Revenue accounts can be defined in more detail by using sub-accounts.

Description of accounts and specifics

Revenue Accounts

Apaleo has the following 5 static revenue accounts:

and each of them has sub-accounts for each VAT type that exists in your hotel's country. Navigate through the account schema in Apaleo to see which ones those are - example below for Germany:

The display of those accounts does not necessarily mean that all those accounts will carry transactions.

How your hotel revenues will be reflected depends on the one hand on your set-up of rate plans and services, on the other hand on how you select the parameter when manually posting charges.

Accounts “RevenueCancellationFees” and “RevenueNoShow” are only available for charges when a reservation has the respective status.

For operational questions, see our guide Handling of Cancellations & No-Shows.

In a rate plan, the service type “Accommodation” triggers revenue charges on account “RevenueAccommodation”:

For a service it works the same. In the example below, the revenue of this service is charged to account “RevenueOther”:

You can also see that next to the service type, the VAT type is defined. The VAT type is applied as valid for each business day.

Please note: the VAT amount and the sub-account can be changed after the set-up with the accounting configurations if needed, earliest applicable from the next day. However this should only happen after confirming it with your Accountant/Tax Advisor. In order to change the settings click on + Add new configuration and change the needed settings:

Please note: If charges or correction for charges are posted not using a predefined service but defined manually, the service type, the VAT type and the sub-account (if available) are each selected. There is no sanity check done by the system if selected parameters make sense, i.e. this is a source for incorrect postings.

8000 Vat on Revenue

# 8000 Vat on Revenue has sub-accounts for each VAT type & rate that exists in your hotel's country. Navigate through the account schema in Apaleo to see which ones those are - example below for Germany:

The VAT type itself is set as described in the revenue section. As soon as a charge is posted or corrected, the associated VAT is booked to the corresponding account. It is not possible to directly book to those accounts.

Payment Accounts

Payment account codes begin with "1."

The Payment account has a number of static sub-accounts each with a specific code and each representing a payment method. For example, a Visa credit card payment is denoted by 1102.

Which payment accounts will be used, is defined by the payment methods you allow and the channels you use.

How payments are posted, depends on the respective set-up. The range is from posting manually to a large degree of automation. Please see our guide Apaleo Payment: What payment accounts are used?.

In the end, you will have to reconcile in your main ledger the payments posted in Apaleo with the actual payments you receive on your bank account. From this perspective you can look at the different payment accounts as a kind of debitor for a payment method, instead of having one global payment account.

The payments as such can balance a receivable for a reservation, an external folio or a house account, or represent a prepayment / deposit by the guest. Apaleo does this qualification automatically.

Comments on some accounts

General payment accounts

Those two are general as they do not specify a payment method as Visa credit card or Visa debit card. In order to reconcile those payment accounts in your main ledger, you need to know where the payment actually comes from.

It is important that you define your use cases and also a guideline for the field “remark”, see below. The remark is captured in the transaction record, hence can be exported, and helps reconciling.

Examples for use cases:

#1100 Credit Card Payment: transfer of credit card payments from previous system:

# 1118 Other Payment: migration of other payments from previous system or used to capture payments from a channel, e.g. reservations from Secret Escapes:

# 1400 Bank Transfer

This account is intended for payments received by normal wire transfer up to departure day.

If a reservation is checked out already but shows an open balance, i.e. amount to be paid, you would close the folio by creating an invoice (AR Invoice). The receivable of this AR invoice is recorded in Apaleo’s account # 9999 Accounts Receivable. A payment by wire transfer for an AR invoice would be reconciled in your main ledger against the account you choose for reflecting Apaleo’s # 9999 Accounts Receivable.

If you allow customers to pay by wire transfer prior departure, you need to establish an adequate process: check of bank account statements and timely post payments to reservations in Apaleo.

Depending on how transactions are reflected in your main ledger, transactions on # 1400 Bank Transfer should be allocated to an interim bank account, not your account for the bank as such.

# 1600 Cash Payment

This account is only intended to capture cash payments for charges posted to a reservation, an external folio or the house account. Or if you need to refund a cash payment as the result of (partially) refunding a charge.

It does not allow you to post cash-outs for any kind of expenses. So Apaleo’s # 1600 Cash Payment account does not return all transactions for petty cash.

Depending on how transactions are reflected in your main ledger, transactions on # 1600 Cash Payment should be allocated to an interim petty cash account, not your main account for petty cash.

# 1116 Voucher Payment

The account should be used if vouchers previously sold are partially or fully redeemed. It is not intended to reflect the sale of a voucher. With regards to reconciliation, you should pay attention on how you recorded the sale of a voucher in your main ledger. For Germany, the keywords are single purpose voucher vs multiple purpose voucher.

Receivables

Apaleo knows 3 types of receivables:

   #1200 Receivables

      #9000 House Account

         #9999 Accounts Receivables

# 1200 Receivables represents the receivables the hotel has against guests in house, those having consumed services which are not paid yet. Those receivables in general come from a reservation, but could also result from transactions on an external folio.

Remember, Apaleo does real-time-accounting. I.e. any charge posted to a folio (of a reservation or an external folio) creates a receivable, any correction posted for a charge reduces the receivable.

Such a receivable can be balanced  in 2 ways:

• by posting a payment using one of the payment accounts;
• or by consumption of a prepayment / deposit - this is done by Apaleo automatically.

Overall, this account will probably be the one with the largest number of transactions, its increase and decrease is a result of the underlying transactions. That means, main ledger will have an accumulated balance for this account, but will not post any transactions to it in order to get the balance down to 0.

Can this account have a balance of 0? Yes, it can. Either you do not have guests in house, or you have guests in house, but all the services consumed have been prepaid.

From a reconciliation perspective, you can retrieve the information which reservations make up the balance at a certain day by using the gross transaction report.

How is the quality of this account ensured, i.e. does the balance make sense? Hotel operation’s task is to have a reservation's balance with amount 0 at check-out or if cancelled or no-show. This can be done by using the predefined view on the reservations - open Balance check.

What leads to a wrong balance:

• guest has departed, but no payment was recorded;
• guest has departed and is allowed to pay on AR invoice (e.g. company guest), but AR invoice is not created yet;
• charges were only paid partially;
• a charge was posted directly on the folio although the guest only arrives in the future.

# 9000 House Account

This account is a separate receivable account the hotel could use for

• posting charges for guest without a reservation, e.g. breakfast consumption by a walk-in, paid immediately;
• moving charges from a reservation because guest complaints and disputes consumption (e.g. minibar), and later refund the charge in a controlled way.

From an accounting perspective, this account should always have a balance of 0 as it is a receivable against the hotel itself.

It is not used that much anymore since the external folios are available. Those are now used for charges of guests not having a reservation. The advantage for the guest is that an invoice can be created.

# 9999 Accounts Receivables

The receivables on these accounts represent those guests you allow to pay after check-out. Normally it is business guests for which you have a cost coverage agreement. This is the fundamental difference to # 1200 Receivables: guest checked-out vs guest in-house.

When hotel operations creates an AR invoice, meaning the invoice is created while having a negative balance on the folio and without having added a payment,

from an accounting perspective, the receivable on account # 1200 Receivables is balanced/credited and a receivable is debited to the respective sub-account of # 9999 Accounts Receivable.

The transaction record in Apaleo looks the following:

Creating an AR invoice is represented by the command: PostToAccountsReceivables

Debited Account is "reservation-id_AccountsReceivable" => reflected in # 9999 Accounts Receivable

Credited Account is "reservation-id_Receivables" => reflected in # 1200 Receivables

Receipt: "Invoice + invoice number" - how to configure the invoice number.

# 9999 Accounts Receivable, containing the collective debtor and the company debtors, collects all receivables from AR invoices. Please see our guide for Company debitor accounts.

The reconciliation of this account is the classic work: check your bank account for payments for those AR invoices, and post in your main ledger: debit bank account to credit account used for # 9999 Accounts Receivable. With no further settings, the account in apaleo will have an increasing balance with no cross-check possibility to balance in main ledger.

Therefore, Apaleo has 2 more options for managing AR invoices:

• AR invoices can be marked as paid in Apaleo and depending on the settings of the function Accounting for invoices that are "marked as paid", a report on unpaid AR invoices can be extracted, allowing to compare the result with the balance in main ledger.
  
  
• Or an additional transaction can be created in Apaleo, reflecting the payment in Apaleo as selected. In order for this process to work, the setting "Balance payment and AR accounts when marking invoice as paid" has to be activated.
  Example: If an AR invoice is paid by wire transfer, and bank transfer is selected as payment method, then the following transaction is created:
  
  debit # 1400 Bank Transfer to credit # 9999 Accounts Receivable.
  
  In this case, Apaleo would be the leading system with regards to accounts receivable.
  For more details, please see AR invoices.

Please note, Apaleo itself does not allow you to run a dunning process.

Liabilities and 8001 Vat on Prepayment

Apaleo qualifies liabilities (aka prepayments / deposits) and the corresponding VAT itself, and also the consumption of those. Transactions on those accounts are a consequence of the status of the receivables and payments for a reservation. You cannot directly book to those accounts. The reconciliation is done against Apaleo only.

How does it work?

When a payment is posted, no matter to which payment account, Apaleo checks for the specific reservation if there is a receivable on account # 1200 Receivable. If this is the case, the payment is used up the amount of the receivable. Any remaining payment amount is automatically qualified as prepayment.

The particularity is that apaleo splits the amount in a net portion which is accounted for in # 3000 Liabilities, and in a VAT portion. Depending on the type of VAT, the amount is recorded to the specific sub-account on # 8001 Vat on Prepayment, example below for Germany:

The base for this split are the future charges on the reservation, taking into account the VAT from the highest rate to the lowest.

Same as qualification as prepayment / deposit, Apaleo consumes prepayments / deposits automatically.

How does this work?

Any time a receivable is created, Apaleo checks if a prepayment is existing to balance the receivable, whereby it is checked if amounts are available on # 3000 Liabilities and on the different sub-accounts of  # 8001 VAT on Prepayment, and if existing, it can be used. The consumption itself follows a set of rules. It is done after each receivable transaction, not by transferring a deposit at check-in from a deposit ledger to a guest ledger. The pure check-in does not create any transaction in accounting. Therefore, the sum of the accumulated balance of accounts # 3000 Liabilities and # 8001 Vat on Prepayment reflects in real-time your liabilities.

Good to know: Any amendment of a reservation leads to a new evaluation of an existing prepayment. If necessary, the split in net liabilities and VAT on Prepayment is adjusted. As the system does not know the final status after an amendment, it may look like redundant transactions.

From a reconciliation perspective, you can retrieve the information which reservations make up the balance at a certain day by using the gross transaction report.

How is the quality of this account ensured, i.e. does the balance make sense? Again, hotel operation’s task is to ensure that a reservation has a balance of amount 0 at its final status. This can be done by using the predefined view on the reservations - daily balance check.

What leads to a wrong balance:

• guest has prepaid, cancels the reservation - no cancellation fee is posted nor a refund done;
• guest has prepaid and does not show up - a no-show fee was not posted and / or a remaining amount was not refunded;
• guest has prepaid and consumes less, e.g. earlier departure. The remaining amount is still on the folio, resulting in an over-paid reservation.

City Taxes

If City Taxes apply for your hotel, the specific calculation and VAT treatment needs to be defined. Please see our guide for Distribution: City Tax.
The City Tax as such is recorded on the static account # 6000 City Taxes. As City Taxes or similar fees in general need to be reported and paid to the specific institution, this account is a balance sheet account, and not taken into account as revenue. 

Transitory Items

This static account # 7000 Transitory Items is intended to collect a payment from a guest for an amount the hotel has paid for the guest on his behalf. Therefore transitory charges do not carry any VAT. This account is a balance sheet account.

Example: guest asks hotel to buy flowers, the hotel expenses for the flowers and posts a transitory charge to the guest’s reservation.

In order to reconcile this account in your main ledger, the cash-out for the expenses needs to be recorded appropriately.

Understanding transactions

The core information in a transaction entry is debited account ("from"), credited account ("to"), and amount. Amounts are rounded to 10 digits to reduce the impact of rounding errors.

For a payment balancing a receivable, the transaction would be:

• "Book 120 EUR From Visa-Credit to Receivables for reservation XTTSQQKW-1":                                    # 1102 Visa Credit Card Payment 120 EUR to # XTTSQQKW-1_Receivables 120 EUR                        The amount is 120 EUR, Visa-Credit #1102 is the debited account, and XTTSQQKW-1_Receivables is the credited account.

There are composite transactions, too. For example, posting a charge leads to this transaction:

• "Book 107 EUR from Receivables to Revenues (100 EUR) and VAT (7 EUR)":                                          # XTTSQQKW-1_Receivables 100 EUR to # RevenuesAccommodation_Reduced:7.00 100 EUR            # XTTSQQKW-1_Receivables 7 EUR to # Vat_Reduced:7.00 7 EUR

• “Cash Payment 94.50 EUR, qualified as a prepayment for future charges with 7% VAT”:                       # 1600 Cash Payment 88.32 EUR to # XTTSQQKW-1_Liabilities 88.32 EUR                                           # 1600 Cash Payment 6.18 EUR to # LiabilitiesVat_Reduced:7.00 6.18 EUR

Those composite transactions are two log entries that share the same entry number.

Additionally, each transaction has a receipt, a command which tells you what happened in the real world, a timestamp for the exact second the transaction was posted to the log, the business date it was posted on, and an entry number.

The receipt is the receipt number, reflecting either the invoice number of an AR Invoice, or the PSP Reference number of an Apaleo Payment transaction, or the remark added during posting, or the reservation-id including the number of amendments. Depending on where transactions are retrieved, the receipt can have in addition a receipt type. The receipt type can be Invoice, PSP Reference, Reservation or Custom.

Possible commands are: PostCharge, PostPayment, PostPrepayment, PostPrepaymentVat and PostToAccountsReceivables. The command reflects the source for the transaction.

Transactions can be retrieved on different levels. Please refer to the section “Retrieving data”.

Business transactions and accounting transactions

The transactions described in the previous section are accounting transactions, and reflect those of all business transactions having an impact on accounting. They are really booked, i.e. the event has happened.

A business transaction triggers everything we record - for example:

• collecting payments and prepayments;
• posting reservation charges during the night-audit and consuming pre-payments;
• adding or refunding charges and payments to a folio;
• creating an invoice with outstanding payments (AR invoice);
• amending a (prepaid) reservation;
• moving charges, for example, from a reservation to another reservation or the house account, or within a reservation from one folio to another one;
• change of a guest name;
• adding extras to a reservation;
• manually add or remove a city tax prior posting.

The place where we record those real-world actions is the respective tab of a reservation, mainly the folio. Reservation changes are reflected there, as are direct postings of charges, refunds, and payments.

Visually, already recorded transactions are reflected in black:

whereas future posting are in grey:

Net vs gross 

Because we do split up revenue transactions into their net and VAT parts, all revenue numbers are net. The revenue accounts are always for a specific VAT, for example, "Revenues Accommodation 7%".

To get the gross amounts, you can

• go to Reports > Revenues, define a timeframe and export the net and gross numbers for that period, or
• go to Finance > Accounting > Export > Finance Export > Total debited and credited, define a timeframe, select revenue accounts and multiply the net amounts with the corresponding VAT, or
• go to Finance > Accounting > Export > Finance Export > Gross transactions, define a timeframe, and select revenue accounts: for each transaction you will see net, VAT amount and type and gross.

Posting vs business date

Each transaction we record has two dates: the posting date and time, and the business date.

The posting time is the exact point in time when we write the transaction log entry. When you add a direct charge, it is the time of adding it. For charges on the reservation, it is the time when you run the night audit. When you create an invoice the night before a guest leaves, tomorrow's charges are posted at the time you click "Create invoice". The posting time is not relevant to accounting. We have it for audits and automatic integrations.

The business date is the one that is relevant for accounting. Imagine you run the night audit only at the end of each month (please don't!): then the posting date will be the end of the month, but the business dates will be the actual days when services were delivered, and revenue was made: each of the past nights of the month.

Whenever you can enter the date and time, Apaleo filters by posting date:

Whenever you can only enter the date - no time - Apaleo filters by business date:

Retrieving data

There are different ways to retrieve data, and it also depends on what you are looking for.

In order to reflect the accounting transactions in your main ledger, you may:

• potentially use one of the finance apps available in the Apaleo Store;
• write your own report/app, based on the gross transaction report and the developers' guide, as all recorded data is also available via the Apaleo APIs;
• manually transfer the data, using the “Total debited and credited” export (Finance > Accounting > Export > Finance Export). In fact, this report is a full balance sheet. Please pay attention to accounts # 3000 Liabilities and # 8001 Vat on Prepayment. Due to the rules of consumption and the split, the amounts per liability / Vat type need to be calculate;
• manually transfer the data, using the gross transaction report and prepare an accounting template based on your needs.

Depending on how you reflect the transactions in your main ledger, you will have a more or less detailed level. This has an impact on your ability to reconcile accounts.

If you would like to retrieve the transactions for a certain period for a specific account, we recommend to use the gross transactions report, by simply filtering on the account you need. Given the structure of the report you can sum up the amounts in one column.

If you would like to see the finance / accounting transactions for a specific reservation, select the reservation, hit the view button and select Finance transactions.

If you would like to see the raw transactions, report Raw transactions in Finance > Accounting > Export > Finance Export is the one to select. Please note that this report reflects each record, from newest to oldest based on timestamp, and the order of debit and credit the transaction was done - it is a journal. That means, you cannot simply sum up amounts, and you would have to filter on business date for accounting purposes. Overall, the report is not useful as base for your main ledger, but rather to extract transactions for an audit or for analysis.

If you would like to check the folio change log, i.e. what was done, you select menu item Audit / Logs, then select Folios. You will see all actions, but you can also filter for a specific folio or different criteria. You may need that for an analysis.

In menu item Reports you will find the revenue report and the cashier report (i.e. reflecting the transactions on account # 1600 Cash payment).

If you would like to see AR Invoices, please go to Finance > Invoices. There you have different possibilities to select and filter.

In general, data can be exported as pdf, as excel or as csv.

Essentials for accountants

We have implemented a number of measurements  so that transactions are recorded in a transparent way, easy to trace and unchangeable.

• Every business transaction having an accounting impact is reflected as an accounting transaction carrying an unique entry number.
• An accounting transaction cannot be made “undone” - it can be cancelled, or refunded - resulting for those new transactions in new entry numbers. Same applies for invoices having an initial, a cancellation and a correction invoice.
• Transactions are hard-coded in the system once they are recorded, they cannot be modified anymore. It also means that they are available at any time.
• Transactions as such have several components which allow to analyze them in depth and easily trace the source of their origin.
• We have log files for folios, reservations and accounting - in case you need to investigate.
• Direct postings on the folio will be recorded on the business date they are added to the folio. This means you cannot add transactions for a past date. Only the night audit is able to do so, as it posts charges for the business date they were intended for. Therefore an automated night audit is highly recommended.
• The setting of revenue account and VAT type in rate plans and services is hard-coded once the save-button is hit. Please remember, if postings are done by manually defining them, mistakes can happen. Therefore we recommend to assign user roles carefully.
• There are several instruments to allow a quality check on accounting transactions. It is up to the hotel operations to make use of it.

Last but not at all least - Please read me :-)

In often happens that an accountant or the external accountant / tax advisor is involved at a late(r) stage, sometimes the hotel is already live. It could be that they are not amused: it is a new system, they do not know how it works, they do not know what they get with regards to accounting, etc.

Therefore we do recommend:

• Involve your accountant rather earlier than later. Best to share this accounting guide with him.
• Consult your accountant for the correct VAT types (revenues, cancellation fees, no-show fees, City Taxes) prior the set-up, and also whenever you would like to change something.
• Consult your accountant on structure and level of detail revenues are needed. Remember, revenues can be detailed by using sub-accounts.
• Decide whether your accountant should retrieve the accounting data himself, which requires that the accountant is an user in Apaleo with role accountant, or if you provide it.
• If you provide the data, align which data, which format and how often (daily, weekly, monthly).
• Think about what you expect from your accountant: just book the accounting data in the main ledger "as is", or also ask him to point out potential errors, i.e. transactions on # 1600 Cash Payment whereas this payment method is not allowed. The underlying question is: who performs the quality checks.
• Decide on process for AR invoices, i.e. to which extend are functions in Apaleo used, and who is responsible for dunning.
• With Apaleo Payment in place, the accountant needs to get familiar with payment methods covered, how a successful transaction can be identified, how settlement reports are structured, read and booked in main ledger, how invoices for payment services are booked and accounts payable reconciled.