In the Accounts Receivable Process for Third Party Delivery services, transactions made hit GL Accounts based on the following:

  • The Customer order is received and entered in the POS and then closed out to unique tender (i.e. Seamless). This imports into R365 as a unique Payment Type and debits whichever GL Account you set up in the Payment Type Accounts, usually a unique Account Receivables account (i.e. A/R - Seamless). Click here to learn more about POS Mapping.
  • When Bank Activity is uploaded, Rules can be configured so each of these delivery service deposits hit their corresponding Accounts Receivable account. The A/R Account gets credited to cancel out the debit from the POS.


A few key points to keep in mind:

  • The GL account should be the same for the Payment Type and Bank Rule if you want them to cancel each other out instead of debiting one account and crediting a different account.
  • The end result of this process should be that the Accounts Receivable account gets debited when imported from POS and then credited when the deposits hit the bank
  • As most Third Party Delivery Services take a percentage of the actual Retail Sales, there will always be a remaining balance in the A/R account. This balance is the Delivery Fee and can be journaled as an expense using a monthly delivery company statement.


Setup for Third Party Delivery Services

 

Navigate to the Payment Type Accounts grid and open each of the Third Party Delivery Service accounts pulled over from the POS. Update the following two fields on each record.



1) GL Account - Update this to the corresponding Accounts Receivable GL Account

2) Payment Group - Set the Payment Group to 'Third Party Delivery' on all Third Party Delivery Payment Types


When finished, save the record before closing.


Processing Third Party Delivery Services in R365

 

When a Third Party Delivery order is received at the restaurant and entered into the POS, it is tendered to a unique Payment Type. Our goal is to automate this process as much as possible with the following elements:

  1.  When the order is rung up in your POS system, they will choose which Delivery Service will be used for payment on the tender screen (the Sales payment will be the Delivery Service instead of Cash, Credit Card, etc).
  2. These transactions will pull into R365 in the nightly DSS import and bring over the Payment Type accounts from the POS. You will need to update record as described in the previous section.
  3.  In the DSS grid, you will now see this Payment Type broken out with its corresponding A/R Account detail, so as long as that tender is in the POS, it is already linked to the account in Restaurant365 and the system will populate this field for you so you do not have to every time. This is a huge time saver. Restaurant365 stores and updates this automatically so it won’t require any user interaction to setup or manage these links between Restaurant365 and Third Party Delivery transactions.
  4.  Most Third Party Delivery Services deposit funds into your account weekly minus their fees. When uploading the bank activity for these accounts, you will need to set up Bank Rules (i.e. Seamless Deposit = A/R Seamless).
  5.  The deposits (credits) will offset the Payments (debits) from the DSS Journal Entries.
  6.  As these deposits are net minus the Third Party Delivery Fees, they will never match the retail payment amounts from the POS. Therefore, the remaining balance in the A/R Account can be journaled as your Delivery Fee Expense using a monthly delivery company statement.


Keep in mind this is only one of several options for handling Third Party Delivery Services. Traditional House Account invoicing can still be used if preferred.