G/L Mapping

The mappings area are where all Inventory Groups and Items that are present on your Transaction Summary Report will allow you to 'map' the Item/Group and description inside of BookingCenter to the account codes & description you use in your accounting system. Further, it will allow you to place an 'offset' account code & description used in your accounting system so that the Transaction Summary GL file generated will also provide an 'offset' posting.  The ability to post whether the file will have a 'credit' or 'debit' label - for either side of the Transaction Summary Ledger GL file - is also manageable in this area.  If the use of credit/debit or offsets isn't important to you, you can ignore these elements when processing the Transaction Summary Ledger GL file.  But if your intention is to post the data to QuickBooks Online Edition, these are required to be setup properly.  

Because the Transaction Summary Ledger GL file is a version of the Transaction Summary report, it is only applicable to single day, (the 'Site date') the MTD (month to date) and YTD (year to date) values are never included.  In addition, for customers who use Direct Bills, the Direct Bill line on the Transaction Summary will not be sent in the GL file since that number is included in the Accounts Receivable Balance and should not be duplicated.

Understanding GL Mappings

The options enabled for mapping to your accounting system GL  include:

Category: this matches the category summary of the Transaction Summary Report and Ledger GL file).  For example, 'TOTAL CREDIT CARDS'

Sub category: this matches the category summary of the Transaction Summary Report and Ledger GL file).   For example, 'Visa'

Account: This is the AccountID setup in your G/L system, such as "0012" where the credit/debit event will post and will be displayed the JSON array as "gl_id": "0012",

Account Description: This is the Account Description setup in your G/L system, such as "RoomRentTotals" where the credit/debit event will post and will be displayed the JSON array as "gl_desc": "RoomRentTotals".

Posting Type: This is where you wish to either Credit or Debit the specific account and will be displayed in the JSON array as "gl_type": "Credit" or  "gl_type": "Debit"

Offset: This is the AccountID setup in your G/L system, such as "0006" where the OFFSET credit/debit event will post and will be displayed the JSON array as "offset_id": "0006",

Offset Description: This is the Account Description setup in your G/L system, such as "RoomRentOffset" where the credit/debit event will post and will be displayed the JSON array as "offset_desc": "RoomRentOffset

Offset Type: This where you wish to balance the Credit or Debit specific account from above ('AccountID') with an 'OFFSET' account which will be displayed in the JSON array as "gl_offset_type": "Credit" or  "gl_offset_type": "Debit".  The "Offset Type" must be the opposite of what the Posting Types was else the 'books won't balance'.

Live: yes/no (you can turn one of the mappings to NOT LIVE to stop it from appearing in your mappings area, but if it's still reporting on the Transaction Summary Report then it will be included in the JSON array sent to your G/L.

*note: The $ amounts (or values) of the Debit/Credit and the matching 'Offset' Debit/Credit can be either positive or negative numbers, but will always be equal to each other.  These values are not shown in the 'mapping area' (they differ each day), but they appear every day in the G/L file and are what gets posted automatically to the Accounts and Offset accounts.  

Totals or Details for Income accounts?

Two 'special condition Groups' called 'Credit Cards' - which are the total of all active Receipt Types set as 'Credit Cards' - and Non Credit Card -  which are the total of all active Receipt Types NOT set as 'Credit Cards' such as CASH, Write-Off, etc. are included as summaries of the 'Credit Card' and 'Non Credit Card' payments for the day.  Each of these matches the values on the Transaction Summary Report for the day.  

If your G/L goal is to update daily Visa amounts separate from American Express amounts, for example, then you must map the Visa Account ID and Description from your G/L separate from the American Express ones and this will map them discreetly. However if you prefer to 'keep to simple' and keep the detail about daily credit card values in your GL as 'Credit Card', then use the category 'TOTAL CREDIT CARDS'  and only the total of the aggregate will be posted to you G/L.  You need to choose one or the other, not both. If you map both detailed credit cards type (such as VISA) and also aggregate 'TOTAL CREDIT CARDS', your G/L will end up with double amounts posted each day.  

The same is true of 'NON CREDIT CARDS', these are payment methods ('Receipt Types') such as CASH, Write-Off, check that can be mapped as detailed NON CREDIT CARDS (such as CASH) or  aggregate 'NON CREDIT CARDS', but you should choose one or the other, not both. If you chose both, your G/L will end up with double amounts posted each day.  

Besides these 2 'special condition Groups', the Transaction Summary Ledger GL file will include all  Items and their respective summary numbers for the day. Your Transaction Summary Ledger GL file will contain all Items and Groups that are present on your Transaction Summary Report.  

Advanced Deposits

The Advanced Deposits balance in BookingCenter (AD) will be sent in the JSON message and will update the G/L account of type 'liability' and that is mapped to the 'BookingCenter Advance Deposit.  If using the Automated G/L Posting Product, the application will query the current balance in your General Ledger for the account mapped to Advanced Deposits as follows: 

 "Advance Deposits" |  "gl_id": "00002" |  gl_desc": "AdvanceDeposit" | "gl_type": "Credit" | "gl_amount": "1345.67",

The application will query the balance of the AD account (in example above, AccountID: 0002), reduce it to 0, then CREDIT the AD account with the current Advance Deposit amount $1,345.67.  It then will make an 'offset' DEBIT posting to whatever the customer setup as their offset account to keep the Advanced Deposit balanced.  The customer can always run the 'Advanced Deposit Report' in BookingCenter to see the details of bookings that supports the Advanced Deposit amount. *note, this balance is dynamic and will likely not be identical if run at a later time, as bookings may have been checked in, canceled, or payments applied to future bookings, thus altering the Advanced Deposit dynamic balance.

Accounts Receivable

From QBOE: Accounts Receivable (A/R) account: needs to have a Customer in the Name Field. The A/R account is visible only after there are A/R transactions such as receive payments from invoices.  

BookingCenter doesn't use the internal QBOEAccounts Receivable (A/R) system.  Instead, your accountant will create an AR account of type 'liability' and description: 'BookingCenter AR' and use the account code (customer-provided) to map to this. This amount will be equal to the AR Ageing Report that was accurate as of the Night Audit event. *note, this balance is dynamic and will likely not be identical if run at a later time, as Company Accounts may have been paid off via an AR payment or DB: payments applied to bookings, thus altering this dynamic balance.  Thus, the customer's GL will end up with an'BookingCenter AR' account that is managed by the GL JSON but the details of which Company owes how much is left detailed in BookingCenter and reflected as a Toal 'liability' nightly in the G/L.

Transaction Summary Ledger GL file

For customers enrolled in the G/L program, BookingCenter will save an endpoint you will provide and during Night Audit, we trigger three messages to you when the System Date increments, as that is the indication that the day ’closes’ in BookingCenter.  This event happens when the staff does it, or if you are set to Auto Night Audit, when that time occurs. This is when the Transaction Summary Ledger GL file will trigger to your endpoint.  The file is a JSON array that is equal to the 'Today' column in the Transaction Summary Report for that specific System Date.  An example is included here:

Sample  Transaction Summary Report output:

Archived and Re-Try Messages

Upon triggering the file to your endpoint, BookingCenter will send an email with the array inside the body to the Property Address on file with a subject: Night Audit GL File <SystemDate> so that you have a backup to view what was posted at Night Audit. In addition, BookingCenter will provide an endpoint where you could validate using your Hotel/Site credentials, then pass in a date (the desired 'System Date'), and BookingCenter will send the message again to your endpoint for that date’s data. The Transaction Summary with that System Date would be identical to what was sent at the initial time (ie, at original Night Audit event, as encapsulated in the archived email). The other Advanced Deposit Balance and Accounts Receivable Balance will likely not be identical, as those balances may have altered since that time, as these are dynamic balances.  But this offers a ‘retry’ method. 

Email Summary

Every night at Night Audit we send an email to the mail of the property with the subject: BookingCenter General Ledger JSON for <Hotel Name> on <date> and you should archive this in case you require a backup and can't access your JSON function.