Print Friendly

Purpose & Overview: 

Payment Type Accounts are required for all POS integrations to Restaurant365 in the same way Sales Accounts are.

A Payment Type Account’s purpose is to tell Restaurant365 what GL Account to debit when accounting for individual sales tickets imported from the POS. It is a ‘mapping’ of tenders, discounts, and other offsets/reductions to the sale of goods in the POS system, to a Restaurant365 GL Account.

Here is a diagram & example:

PaymentTypeAccounts1

The Restaurant365 POS integration automatically creates unique Payment Type Account records (in R365) for every payment & discount from sales tickets imported from the POS to R365. Each of these newly created Payment Type Accounts must be manually mapped to a GL Account during setup and assigned to a R365 Payment Group (as highlighted in yellow above.)

The full list of Payment Type Accounts created from the integration with your POS can be seen in the Payment Type Accounts list view, accessed from the navigation pane. To get there, click on the Accounting module in the lower left, then Payment Type Accounts under the Administration node on the navigation pane. From this view it is easy to identify which Payment Type Accounts need to be assigned GL Accounts and assigned a Payment Group:

Field-by-Field Description of Payment Type Accounts

Payment Type – This is the name given to payments and discounts in your POS system that was imported into Restaurant365. Restaurant365 uses this as the name of the Payment Type. Never manipulate or change the value in this field. Leave it as it was imported from your POS solution.

GL Account – This is selected manually on each Payment Type Account. Examples of the typical GL Accounts assigned are listed below in the Payment Group section. ***Special Note: All amounts booked to the GL Accounts from Payment Type Accounts will be debits on the Daily Sales Summary Journal Entry.

Payment Group – Assign a Payment Group to each Payment Type Account.

Cash – This is selected for the POS Payment Type used when receiving cash from customers. The GL Account you want to assign to this type of Payment Type will either be a cash account (i.e. Checking Operating) or the ‘Undeposited Funds’ account (an asset account representing money collected at the store but yet to be deposited in your bank).

Catering Receivable – This is used for the Payment Type used when you record the sale of a catering job but don’t accept a full payment from the customer at the time of sale. A receivable will be recorded. Typically, the GL Account is a ‘Catering Receivables’ asset account.

Credit Card – Combined – This is used to group credit card tenders received in the POS into a single deposit for bank reconciliation purposes in Restaurant365. Typically, you will assign your VISA, MASTERCARD, and DISCOVER Payment Types – all to this group. And the GL Account you normally would assign to these is your bank account where these funds are deposited from your merchant services provider or the ‘Undeposited Funds’ account (an asset account representing money collected at the store but yet to be deposited in your bank).

Credit Card – Individual – This is used for all credit card payment types that hit your bank individually, such as American Express. For these, you would typically assign it the bank account where these funds are deposited each day or the ‘Undeposited Funds’ account (an asset account representing money collected at the store but yet to be deposited in your bank).

Coupon – This group is used for all coupon Payment Types and is used to group these types of Payment Types on reports. The typical GL Account used for these is a ‘Coupons’ contra-revenue (or expense) account. If you don’t want to track this separately, you could assign it directly to a ‘Food Sales’ GL Account, in which case on your financial statements you would just see Net Sales instead of Gross Sales with the coupons on a separate line.

Comp – This group is used for all comp Payment Types and is used to group these types of Payment Types on reports. The typical GL Account used for these is a ‘Sales Discount & Comps’ contra-revenue (or expense) account. If you don’t want to track this separately, you could assign it directly to a ‘Food Sales’ GL Account, in which case on your financial statements you would just see Net Sales instead of Gross Sales with the comps on a separate line.

Discount – This group is used for all discount Payment Types and is used to group these types of Payment Types on reports. The typical GL Account used for these is a ‘Sales Discount & Comps’ contra-revenue (or expense) account. If you don’t want to track this separately, you could assign it directly to a ‘Food Sales’ GL Account, in which case on your financial statements you would just see Net Sales instead of Gross Sales with the discounts on a separate line.

Gift Card – This group is used for the Payment Type associated when a customer uses a gift card to pay for their food. Typically, the GL Account used for these Payment Types is the account you use to record your total amount of outstanding sold gift cards, such as a liability account called ‘Unredeemed Gift Cards’.

Special Note: When you record the sale of Gift Cards, you will credit your ‘Unredeemed Gift Cards’ GL Account (this is mapped on the Gift Card Sales – R365 Sales Account). It typically isn’t a revenue account because you have not yet delivered any goods or services. When your customers redeem their gift cards, you will record a payment using all or part of a Gift Card – R365 Payment Type. It is intended that this will then reduce the amount you owe (or in other words, are liable for). The revenue is recognized by the sale of the food and beverages sold. Often, multi-unit operators will sell gift cards that can be redeemed at any of their store locations. If this is the case, you will want to periodically look at the balance sheets of each location and make adjusting entries to true up the liabilities. If your locations are all part of the same legal entity, there will be no reconciling effort needed as all increases and decreases for all stores will hit the same GL Accounts.

Void – This is used for accounting for voids made in your POS. Typically, you would assign these Payment Types directly to a ‘Food Sales’ account as they represent food not prepared or sold. There is only a Void on a transaction if there is a corresponding sales item on the ticket. It is like deleting, but keeping a record of it on the ticket. You may have a separate void payment type for wine or beer, in which case you would assign those Payment Type Accounts to their respective GL revenue account (i.e. Wine Sales or Beer Sales). It is important to note that voided line items do not have any effect on the end of day journal entry.

P.I.A. – This is for Paid In Advance Payment Types in your POS system. Meaning, the customer has already given you a deposit (which you previously recorded as a liability) and now you are applying that customer deposit as payment. Typically, the GL Account you would assign to these would be the same account you used to record the Customer Deposit (a liability account).

House Accounts – This is for sales on account when a customer is putting the sale on terms. You will want to assign these Payment Types to an “Unbilled House Accounts” GL Account – a receivable. These amounts will stay in this account until the House Account billing process in Restaurant365 is complete. That process will credit the ‘Unbilled House Accounts” receivable account and debit the “Accounts Receivable” account when invoices are created and sent to customers (which will then include those amounts on the AR Aging).

PaymentTypeAccounts2

This is an Exception Type – Selecting this field on individual Payment Types tells the system to track each time this Payment Type is used and allow closing store managers to explain why it was used. When a Payment Type is flagged as an ‘Exception’, it is displayed on the Exception tab of the Daily Sales Summary transaction as shown below. Closing store managers can assign employees and add reason comments for each use of this Payment Type. For example, you might flag a ‘20% Discount’ Payment Type as an Exception so that managers can make a note as to why they authorized the discount.  Note: assigning employees, and adding Reasons to Exception Types is not a requirement and the Manager can still save and approve the Daily Sales Summary during the review process.

Payment Types flagged as Exceptions, that are included on the Daily Sales Summary transactions, also appear (along with the comments assigned to them by the closing store managers) on the Daily Flash Report.

Here is an example of how the Exception Payment Types are displayed on the Flash Report:

PaymentTypeAccounts3

Exception Comment – This field is optional and is used to default a standard comment in the ‘Reason’ comment field on the Daily Sales Summary transaction for that particular exception Payment Type.

The Reason comment field on the Daily Sales Summary transaction for exception Payment Types is an optional field. If a Reason comment is frequently used, it can be automatically assigned by adding it as the exception comment on the Payment Type. The Exception Comment field on the Payment Type setup allows you to enter a default comment that will appear in the Reason field on the Daily Sales Summary so the manager doesn’t have to type in a value.

The comment is only a default and may be changed by the manager, if desired, directly on the Daily Sales Summary transaction. In the screen shot above, the ‘COMP’ exception Payment Type has an Exception Comment of ‘Employee Meal.’ but the manager erased them and added custom reason comments to the first three tickets (#91, #51, #52).

 

Consolidate On Flash – There are certain ‘Exception’ Payment Types that are frequently used that you are interested in tracking as a whole but not so concerned about analyzing individual instances. An example might be ‘50% EMPLOYEE’ (for employee meal discounts). By selecting the Consolidate On Flash check box for that Payment Type, the system will sum the total number of instances this Payment Type was used during the day and display the total count of instances it was used and the corresponding total dollar value on the Flash Report (and hide any individual comments that happen to be added to these Payment Types on the Daily Sales Summary transactions.)

  

Assigning Payment Type Accounts on an On-going Basis

After the initial setup, and all the Payment Types have been mapped to GL Accounts, there are occasions where new payment types are added to the POS system. On the day these are used in the POS system, the Restaurant365 integration will pick these up and auto-create a new Payment Type that will need to be assigned a GL Account and flagged with the proper Payment Group. There are three places to administer this on an on-going basis.

  1. Using the Payment Type Accounts List view as described above.
  2. The Accounting To-Do List Dashboard displays a list of any Payment Types missing a GL Account (as shown here below).
  3. On the Journal Entry tab of each Daily Sales Summary transaction, there is an ‘Assign’ button whenever a Payment Type Account associated with that day is missing a GL Account. The Payment Type Account Setup screen can be accessed directly from the Daily Sales Summary record by clicking on the ‘Assign’ button highlighted below. This makes it easy to quickly assign the GL Account and then Approve the Daily Sales Summary transaction.

 

That covers the Payment Type Account Overview. Thank you for attending this training session. This article is one of many training sessions available to you on-demand. We invite you to continue your training so that you can get the most out of Restaurant365 to help your restaurant reach it’s full potential.

Was this article helpful to you?

Comments are closed.