Payment Type Accounts

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.

The POS Mapping Tool can map new and unmapped Payment Type Accounts brought in from the POS. Click here to learn about the POS Mapping Tool.

Navigation

The Restaurant365 POS integration automatically creates unique Payment Type Account records (in R365) for every payment and 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.

Navigation Steps

Open the Admin app.
Expand Sales & Forecasting.
Click Payment Type Accounts.

Search

Navigate to pages with the R365 global search bar:

Enter all or part of the page name in the R365 global search bar.
Select the page from the results list.

Only enabled pages can be searched for. If the desired page is not enabled, contact your CSM for assistance.

Payment Type Account Record

Field

Description

Payment Type

The name assigned to payments and discounts in your POS system and imported into Restaurant365. This field should never be edited or changed—keep it exactly as imported from your POS.

GL Account

Selected manually for each Payment Type Account. All amounts posted from Payment Type Accounts will appear as debits in the Daily Sales Summary Journal Entry. Typical GL accounts used depend on the assigned Payment Group.

Payment Group

Categorizes each Payment Type Account into a Payment Group. This assignment determines how the system groups the transactions for reporting and GL purposes.

Payment Type Group	Description
Cash	Used for POS Payment Types when receiving cash from customers. Typically mapped to a cash account (e.g., Checking Operating) or the Undeposited Funds asset account, representing money collected but not yet deposited.
Catering Receivable	Used when recording a catering sale without full payment. A receivable is created. Typically mapped to a Catering Receivables asset account.
Credit Card - Combined	Used to group credit card tenders (e.g., VISA, MASTERCARD, DISCOVER) into one deposit for easier bank reconciliation. Typically mapped to a bank account receiving the deposit or the Undeposited Funds account.
Credit Card - Individual	Used for credit card types like American Express that deposit individually. Typically mapped to the respective daily deposit bank account or Undeposited Funds.
Coupon	Groups all coupon Payment Types for reporting. Typically mapped to a Coupons contra-revenue (or expense) account. Optionally, map directly to Food Sales for net sales-only reporting.
Comp	Groups all comp Payment Types for reporting. Typically mapped to a Sales Discount & Comps contra-revenue (or expense) account. Optionally, map directly to Food Sales for simplified reporting.
Discount	Groups all discount Payment Types for reporting. Typically mapped to a Sales Discount & Comps contra-revenue (or expense) account. Optionally, map directly to Food Sales for net sales-only presentation.
Gift Card	Used when customers pay using gift cards. Typically mapped to Unredeemed Gift Cards, a liability account. When a gift card is sold, revenue is not recognized until redeemed. Gift card redemption reduces the liability, and revenue is recorded based on the items sold. Multi-location operators should periodically adjust for inter-store liabilities if stores are in separate legal entities.
Void	Used for voids in POS. Typically mapped to Food Sales or specific GL accounts (e.g., Wine Sales) depending on the item voided. Represents deleted sales while keeping a record. Voided items do not affect end-of-day journal entries.
P.I.A.	Stands for Paid in Advance. Used when a customer deposit is applied as payment. Typically mapped to the same liability account used to record the original deposit.
House Accounts	Used for sales placed on terms. Mapped to an Unbilled House Accounts receivable account. Once invoiced, the balance moves from Unbilled House Accounts to Accounts Receivable. Important: Never map directly to Accounts Receivable to avoid duplicate debits/credits and inaccurate AR Aging reports.

This is an Exception Type

When selected, this flag designates the Payment Type as an exception. The system will then track each use and allow store managers to explain its usage. These entries appear on the Exception tab of the Daily Sales Summary. Managers can assign employees and add notes for context (e.g., justifying a 20% discount).

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.

Exception Types

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:

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 directly on the Daily Sales Summary transaction if desired. In the image 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 may be 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. It will also 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 to a GL Account and flagged with the proper Payment Group. There are three places to administer this on an on-going basis.

Using the 'Payment Type Accounts' List
The Accounting To-Do List Dashboard displays a list of any Payment Types missing a GL Account
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