Overview of the Accounting for 3rd Party Delivery Services
Here is a recap of the accounting (debits and credits) in the Accounts Receivable Process for 3rd Party Delivery services. These transactions 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 setup in the Payment Type Accounts, usually a unique Account Receivables account (i.e. A/R - Seamless)
- When Bank Activity is uploaded the Bank 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 clarifications:
- 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 Account Receivable account gets debited when imported from POS and then credited when the deposits hit the bank
- As most 3rd 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 3rd Party Delivery Services
Under Payment Type Accounts:
- Set Payment Group to Credit Card - Individual on all 3rd Party Delivery payment types.
- Map each Payment type to their corresponding Accounts Receivable GL Account
Detailed Walkthrough of 3rd Party Delivery Services
When the 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:
- In your POS system, when the order gets rung up 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)
- These transactions integrate to Restaurant365 in the nightly import and the payment type accounts will pull over from the POS. You will need to update the payment type account in Restaurant365 after it gets created the first time to mark it as Credit Card - Individual so that it is broken out as a unique transaction. As well as specify the Accounts Receivable GL Account for the payment type so it always goes to the right account.
- 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 don’t 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 3rd Party Delivery transactions.
- Most 3rd Party Delivery Services deposit funds into your account weekly minus their fees. When uploading the bank activity for these accounts you will need to setup Bank Rules - i.e. Seamless Deposit = A/R Seamless.
- The deposits (credits) will offset the Payments (debits) from the DSS Journal Entries.
- As these deposits are net minus the 3rd 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 only one of several options for handling 3rd Party Delivery services. Traditional House Account invoicing can still be used if preferred.