In this article
The deposit functionality is fully payer-based. All deposit-related processes — collection, validation, consumption, refund and balance control — are driven by the Payer No., which can be either a Business Central Customer or an LS Central Member (Guest). All information about deposits can be found on the Reservation Deposits page.
A deposit on a reservation belongs to a specific (Invoice Type, Payer) pair, not to a single folio. One reservation can therefore have several deposit pools at the same time — for example one for the Guest payer (the member contact) and one for the Company payer (the customer). Each pool is independent: the deposit collected by one payer cannot be applied to another payer's charges. The same pool can, however, fund any folio that belongs to the same payer and invoice type. Refunds and balance views are presented per payer, and on the POS web template (Accrual mode) the folios appear grouped under their payer with payer-level Pay and Refund buttons. See Hotel POS for the POS side, and the Payer Balance FactBox on the Reservation Deposits page for the back-office overview.
Group reservations and paymasters: the payer-based behaviour applies the same way to group and paymaster reservations. When a paymaster collects, refunds or consumes a deposit, the (Invoice Type, Payer) pool is shared by all reservations linked to that paymaster. Schedule regeneration triggered by a paymaster rate change propagates to every linked sub-reservation; the payer-level POS Pay and Refund buttons act on every folio under that payer in one operation.
You can access this page in three ways :
-
From the Deposit Due link in the Summary FactBox on the Hotel Reservation Card
-
From the Deposit Policy field on the Hotel Reservation Card (under the General FastTab)
-
From the Invoice Management page, where the Reservation Deposits action is available
Deposit Policy
Within the LS Hotels system there is this deposit schedule, deposit due, deposit policy flow. But you can also collect and manage your deposits without this setup. But just to clarify the basics for this flow to work you need to have a Deposit Policy and set it on a rate code, that will then trigger the deposit schedule lines, that will combine in a deposit due amount.
A Deposit Policy allows you to create different deposit rules that define how and when deposits should be scheduled for collection.
You can assign a deposit policy to a Rate Code. When a rate code with an assigned deposit policy is used, all reservations created with that rate will automatically generate a deposit schedule based on the selected policy.
Any changes made to the reservation before it is set to In House status (checked-in) will automatically update the deposit schedule accordingly. Once In House, the deposit schedule will no longer be updated. At that point, the guest has arrived, and deposits (prepayments) are expected to have already been collected.
The deposit flow starts with a deposit policy. If a reservation rate has a deposit policy setup, deposit schedule entries are created.
Collection
The deposit schedule serves as a guideline only. No automatic financial transactions or collections are performed by the system, they are collected manually. You can use the action Collect Deposit from the Deposit Schedule FastTab to collect the deposit based on information from the deposit schedule line. Same way if you need to refund a deposit based on information from the schedule you click the Refund Deposit action from the Deposit Schedule FastTab.
Note: The only difference using these actions instead of the ones from the Deposit Enties FastTab is that when opened it will have all information, like Invoice type, Payer No and Deposit amount already set on the collection page and uneditable.
You can also collect deposit without using the deposit schedule as a guideline. To do so you click the action Collect Deposit from the Deposit Entries FastTab. From there the collection deposit page opens where you can specify the Invoice Type of the deposit, the Payer No. (who is the payer for this deposit) and lastly the deposit amount.
The Payer No. lookup is now restricted to payers who already have a folio of the selected Invoice Type on this reservation — this prevents creating an orphan deposit attached to a payer who has nothing to settle. If no folio of that Invoice Type exists, a message explains why and the picker is suppressed. When the Deposit Amount exceeds the displayed Payer Balance a warning is shown ("The deposit amount X exceeds the balance for this payer which is Y") — the user can still confirm if it is intentional.
Consumption
Deposit consumptions are only done in the Night audit process for account methods "Accrual Accounting" and "Checkout Accounting". This is set from the Hotel Setup page under Night Audit FastTab. The "Blank" accounting method does not run night audit and therefore the deposit consumption is done throught the sales invoices using deposit account directly on the sales invoice line or through POS using the statement postings.
The Night Audit processes Detailed Revenue Entry lines based on the reservation date and status. Only reservations with a status of In House or Checked Out are processed by the Night Audit. When processing the revenue lines it will check if there is deposit available to consume based on payer no./invoice type. So deposit for "Stefan" will only be consumed by revenue line set to payer No. "Stefan". It will continue consuming for each revenue line until either there are no more revenue lines left to process or until the deposit as been fully consumed.
The deposit consumption is posted to the Reservation Payment Entry table and the Deposit Consumed table, you can find this table from theHotel Invoice Management page - General Ledger List - Acions - Deposit Consumed. This Deposit consumed table will contain all consumptions the night audit has done.
When running the Hotel Job, Night Audit process, manually, you can specify a "Start Date for Posted DRE" which acts like a from date and "Date" that acts like a to date. The Night Audit will then process all applicable revenue entries within that date range.
The night audit creates a General Journal when processing the revenue lines, using the Night Audit Journal Template and Night Audit Journal Batch defined in Hotel Setup. Deposit postings are kept in a separate batch whose name is the first seven characters of the Night Audit Journal Batch followed by PAY (for example, a batch named NIGHTAUDIT posts deposits to NIGHTAUPAY). Both batches are deleted and re-created at the start of each night audit run, and are left in place afterwards so you can review or manually correct any lines that failed to post.
See also more detailed information about the Night audit process here.
Refunding
In case you need to refund the deposit previously collected, a Refund Deposit button is available from both Deposit Entries FastTab or Deposit schedule FastTab on Reservation Deposit page. Clicking it opens the Deposit Payment page in refund mode (caption switches to Refund [Type] Deposit) — the same page used for collection, with the Original Receipt No. and Payer Refundable fields enabled.
The page supports two refund modes:
-
Payer-balance refund — leave Original Receipt No. empty. The system refunds against the payer's overall refundable balance. Internally it walks the payer's deposits in reverse order (most recent receipt first) and allocates the amount across them, creating one refund entry per receipt touched, so the original audit trail, card reversals and reconciliation remain intact.
-
Receipt-based refund — pick or type a specific Original Receipt No.. The refund is tied to that receipt, and a confirmation "Continue with refund for receipt?" appears before posting. Receipts that have been fully refunded are hidden from the lookup; the same filter is applied when the receipt is typed directly, so an invalid or already-refunded receipt is rejected immediately.
The Payer Refundable read-only field shows how much can be refunded for the selected payer: deposits collected − refunds already posted. Note that this value is not reduced by deposit consumption — a payer can always recover the full amount they paid, even if some of it has already funded charges. When that happens in Accrual Accounting mode, the next Night Audit run automatically reverses the consumption of the affected revenue lines, so the corresponding charges become unpaid again and can be settled with a different tender or card. Blank Accounting does not run Night Audit; in that mode the consumption is reopened directly through the POS Statement and Sales Invoice posting paths.
If Refund is on and no amount has been typed yet, the Deposit Amount is pre-filled with the negative of the Payer Refundable — so a full payer refund is a one-click confirmation. The amount must be entered as negative; positive values trigger an immediate error.
The same refund flow is available from the POS web template — see Hotel POS for the payer-level and folio-level Refund buttons.