General Ledger

For customers who are subscribed to the General Ledger (GL) postings interface, BookingCenter provides a service to map the Transaction Categories, Inventory Items, and Receipt Types so that your General Ledger (GL) can be keep current - automatically.  The service posts each day's Transaction Summary to your GL system, either manually or via a machine process as a JSON array, that has been 'mapped' to the GL system you use.  BookingCenter can provide this mapping as a service for customers of Quickbooks Online Edition, but we are happy to work with other web-accessible GL systems, as well.  Contact us for assistance.

Each day at Night Audit, the Transaction Summary report provides a detailed listing of all financial events that happened 'today'.  This report contains both 'totals' (for example, all credit cards) and also 'detail' (summarizing all Visa transactions).  Your GL system will either track these 'details', the 'totals', or a mix of the two.  The JSON array we provide allows the mapping to your GL to automatically of the Transaction Summary using the 'details', the 'totals', or a mix of the two to your target GL codes.

Transaction Categories

There are special Categories that BookingCenter uses to bring together concepts such as RENT, TAX, Advance Deposits, etc.   These 'categories' allow a GL system to post the Total of all RENT associated charges, for example. Or your Advanced Deposit totals.  Or a single Total for 'TAX' even if your property collects 3 separate taxes on a folio. Generally, the simpler the better.

GL Mapping

The mapping of the Totals or Details is done via the GL Mappings Area. You can Add, Delete, or Edit any entries here. It is best to have a plan before mapping, and have a clear idea how the Transaction Summary data will be used for your GL.  The following options explain how to map Charges and Payments and the Category your GL needs:

Category: a Charge or Payment can only be mapped one time, so the way the mapping is accomplished is to have a user (often an accountant or bookkeeper) map the Category Total or an Inventory Item (found on the 'Charge' side of Folios) or Receipt Type (on the Payment' side of Folios) to a GL account.  For example, NON CREDIT CARDS Is a Category comprising Receipt Type details such as CASH, CHECK, WRITE-OFF, etc).  Once a category or Item has been mapped, it cannot have another mapping to assure that there are no duplications.
Sub Category: A Charge or Payment is a 'Sub category' totaled via the Category.  Thus, for example, CASH is a sub category of NON CREDIT CARDS. Visa is a sub category of CREDIT CARD.
Account: Your General Ledger (GL) code, usually an alphanumeric string, is what is placed here. This is what a machine will use to post to the amount to the correct GL account.
Account Description: Your General Ledger (GL) description, usually a text description.  This description is not usually used for a machine to post to a GL account, rather used by humans to understand the data.
Posting Type: The JSON array can use a label 'Credit' or 'Debit' to include here for the automation.  BookingCenter doesn't care whether you use the label 'Credit' or 'Debit', but if you are posting to both sides of your GL, pay attention to make sure the GL code for 'credit' is offset by a posting to the 'debit' account.
Offset:  Your General Ledger (GL) code used to offset the posting to the 'Account' section above.           
Offset Description:  Your General Ledger (GL) description used to offset the posting to the 'Account' section above, usually used as a description only and not to actually machine-map a posting.
Offset Type: The JSON array should have the opposite posting type for the offset to what is being used for the Posting Type above.
Live: This is a simple way to turn OFF a mapping for testing purpose. Deleting the mapping will perform a similar function.

Receiving the JSON Array

Once a customer has signed up for the General Ledger service, their daily JSON array that can be accessed via the following methods:

1. A unique URL we provide that uses an API key to keep secure each client's data.  This string requires a customer to place a date into the string to receive the array of data for that specific day, and that data must be earlier than the current System Date.
2. BookingCenter can provide a simple web form that can be placed on your accountant's secure page that enables a date entry to acquire the JSON array.
3. BookingCenter sends an automated daily email at Night Audit with the JSON is embedded into an email so that it an be human- or machine-read from whatever tool a customer uses.  This email is also a 'backup' file that can be kept for a long as necessary to validate what occurred at Night Audit.

Because the JSON will always equal the Transaction Summary data, one can always go backward in time to request the array again. Just as someone can go back and request the Transaction Summary report, for example, Feb 20, 2023.

The Date of the GL JSON data.

Because BookingCenter creates a General Ledger GL array of data that matches the Transaction Summary data, it is important to understand that the date requested must be earlier than the current System Date.  This is because a GL should only be machine-updated once per day, at Night Audit, so the feature is meant to be run immediately after Night Audit. One can automate this feature using either Manual or Automatic Night Audit. Because the JSON will always equal the Transaction Summary data, one can always go backward in time to request the array. Just as someone can go back and request the Transaction Summary report, for example, Feb 20, 2023.

Understanding Advanced Deposits and Accounts Receivables

Because BookingCenter contains all details about a property's current 'liability' for Advanced Deposits and Accounts Receivables, we treat these categories special. Some PMS systems attempt to credit and debit each Payment and Charge to attempt to keep the GL up-to-date with these two important liability accounts. But to do this accurately, each payment / credit to a Folio, as well as all cancellations and cancellation reconciliation, require that the operator makes a proper association for the Payment and Charge to update the GL with exactly what the payment, refund, or charge is supposed to credit/debit.  This is too much complexity for most Users of a PMS, and has no value to a property attempting to clearly understand their Advanced Deposits and Accounts Receivables liabilities.  Instead, BookingCenter uses 'now' to post the total of the Advanced Deposits and Accounts Receivables amount to the GL, and all detail can be found in the respective PMS reports: Advanced Deposit and  Accounts Receivable Aging.

Direct Bills 'paying' a Folio and Companies 'paying' their Accounts Receivables accounts.

Because the Direct Bill 'payment' is entered by a User and immediately adds to the Company's 'account receivable', this payment to a Folio, creating the liability, is shown on the Transaction Summary report, but is not included in the JSON array. It is not included because the Total Accounts Receivables is included in the GL JSON data and thus is captured in your GL as soon as the JOSN is built.

When a Company 'pays down' their Accounts Receivable account, that payment (by check, Visa, wire, etc) is included in the JSON array since it affects a payment Category (CREDIT CARDS or NON CARDS, for example) and the amount paid to the Accounts Receivable account is reduced by that payment immediately. If a property was to run a past date for a JSON array, the Accounts Receivable will always report 'today' and not attempt to assess what theAccounts Receivable liability amount was at that past date.   It is always 'now'.

Advanced Deposits

The Advanced Deposit number included in the JSON array is also, as in Accounts Receivables, always 'today'. The amount reported here will be whatever the Advanced Deposit report was as of the Night Audit event that triggered the JSON to be delivered.  Thus if a property was to run a past date for a JSON array, the Advanced Deposit will take 'today' and not attempt to assess what the Advanced Deposit amount was at that past date.   It is always 'now'.

Automating the JSON to a General Ledger GL System

Because BookingCenter is designed for properties to manage simply, taking advantage of the checks built-into MyPMS, we reduce the complexity for Users and avoid complexity of managing the Accounts Receivable and Advanced Deposit liabilities accounts in your GL. When issuing Payments and Charges to Folios, as well as Cancelling and Editing Bookings, the traditional Guest Ledger and City Ledger required Users to allocate these events to specific GL code(s) to decide what account to credit/debit.  Instead, because of the checks built-into MyPMS, GL automation keep the daily activity 100% accurate, while avoiding duplication of managing the Accounts Receivable and Advanced Deposit liabilities accounts in both the PMS and the GL.  When automating your GL, BookingCenter does this by 're-setting' the daily Accounts Receivable and Advanced Deposit liabilities account totals, and then posting the new number each day.  For example, if the GL account for Accounts Receivable was $1,250 'yesterday', we read that total, offset it with a -1250 entry, then post the current (ie 'today') Accounts Receivable amount that was accurate as of Night Audit and detailed in the Accounts Receivable Aging report. We do the exact same thing with the Advanced Deposit liabilities account.  This saves a property a lot of accountant time and frees up staff to focus on guests and the art of hospitality - not allocating Payments & Charges to Folios and Cancellations & Edits to specific GL accounts to track these events in a GL system, 

Examples of a GL JSON array

Below are examples of what is provided in our JSON: