A POS-to-accounting integration can distinguish sales, tax, tips, fees and settlement only if those amounts are available in the source data and mapped to the right accounting destinations. Before launch, ask the vendor to show you a complete day's entries, including a refund and the related payout.
Start with the restaurant POS reports you already use to close a shift. Then compare each field with what actually appears in accounting. Matching a bank deposit is a separate check: a deposit can be correct even when sales and tips are combined or a fee is missing from its proper category.
Map the source fields before choosing accounts
Get a sample daily sales report, tender report and settlement report. If you also take restaurant online ordering, include an order from that channel. Ask which system owns each number and whether the accounting integration receives a transaction, a daily summary or a payout summary.
Use the worksheet below as a starting point. The destinations are examples, not a prescribed chart of accounts. Your accountant should confirm the account names and treatment for your restaurant.
| Source field | Example destination | Question to resolve |
|---|---|---|
| Gross sales and discounts | Sales and discount accounts, or net sales | Are discounts separate, and do they reduce the sales total sent to accounting? |
| Sales tax | Tax payable | Is tax separated from sales, including on refunds? |
| Tips | Tips payable or another accountant-approved account | Are tips separate from sales and assigned to the correct business day? |
| Cash and card tenders | Cash and card clearing accounts | Can each tender be traced without counting it as a second sale? |
| Refunds and voids | Reversal or adjustment to the original categories | Which business day receives the adjustment, and is the original transaction referenced? |
| Processing fees and payouts | Fee expense, clearing and bank | Does the processor supply the fee, and how is the payout linked to the clearing balance? |
Walk through the table with one real report format from each system. For every row, record the exact field name, account and report date in your own worksheet. Ask whether the mapping can split food and beverage sales if your reporting needs that detail. Also check gift cards, service charges and third-party orders if you use them; each may need its own destination or handling rule.
A tender tells you how a guest paid. It is not another sale. For example, recording a card payment as sales after already posting the underlying food sale would count the same revenue twice. A clearing account can hold card activity until the processor's payout is recorded.
Decide who supplies fees and settlement details
A card processor may collect the guest's payment and deposit a smaller amount after deducting fees. The POS sales report, processor statement and bank feed can each show a different part of that path. Ask the vendor which source supplies the gross card activity, the fee and the payout, and which system creates each accounting entry.
Keep the measures distinct. Sales describe what was sold after the agreed adjustments. Tips are amounts collected for staff, not processing fees. A deposit is cash arriving at the bank; it can be lower than card receipts because of deductions or timing. The fee shown on a processor statement is not necessarily the all-in cost of operating the POS and accounting integration.
Request a written breakdown of recurring software charges, transaction-based charges and any setup or exception-handling costs relevant to your quote. Separately, ask whether a processing fee is posted automatically or must be entered from the processor statement. A low quoted processing fee does not answer whether the accounting records will show that fee correctly.
Check how the connection handles payouts spanning more than one business day, delayed settlements and deductions other than ordinary processing fees. If a fee arrives in accounting from both the integration and the bank feed, decide which entry is authoritative and how the duplicate will be avoided. If no fee detail is available, plan who will enter and review it.
When comparing restaurant integrations, ask whether the accounting connection you need is available for your setup, what data it sends and whether any part requires a separate tool. A connection listed as on request needs a specific availability and setup discussion; do not assume it is already active.
Work through a sample day with a refund
The following is a hypothetical, simplified card-only day. It illustrates the accounting checks, not a particular product's behavior. Assume the sale and refund belong to the same business day, the processor settles the entire remaining amount in one payout, and no other activity affects the clearing account.
- Gross sales are $1,000. Discounts are $100, leaving $900 in sales before the refund.
- Tax is $90 and tips are $60. Card receipts before the refund total $1,050: $900 + $90 + $60.
- A $110 refund reverses $100 of sales and $10 of tax. Net card activity is $940.
- The processor deducts a $20 variable processing fee. The payout is $920: $940 minus $20.
For this example, the $20 fee is included. Fixed software costs and other variable charges are excluded. The stated refund is included; other exception costs, such as a dispute charge, are excluded. The figures do not represent an all-in operating cost.
After the refund, the daily summary has $800 in net sales, $80 in tax and $60 in tips. One simplified set of entries is:
- Record the net day: debit card clearing $940; credit sales $800, tax payable $80 and tips payable $60. Debits and credits both total $940.
- Record the processing fee: debit processing fee expense $20; credit card clearing $20.
- Record settlement: debit bank $920; credit card clearing $920.
The clearing account receives a $940 debit and $940 in credits: $20 plus $920. It returns to zero for this isolated day. The entries are shown net for clarity; a system may instead post the original sale and a separate refund, provided the resulting categories and totals agree. Confirm the desired presentation with your accountant.
Now use the same logic on a sample generated from the vendor's workflow. Can you trace the refund to its original sale? Does tax reverse separately? Does the payout leave an unexplained clearing balance? A correct $920 bank deposit alone would not prove that the $800, $80 and $60 were classified correctly.
Resolve exceptions before the launch date
Ask the vendor and accountant to review the less tidy cases that occur in your restaurant. A refund on a later day, a void before payment, a partial tip adjustment or a missing category can change what the daily report should contain. Agree on whether an adjustment appears on the original business day or the day it was processed, and how staff will find it.
Check the cutoff used by each system. A POS business day that runs past midnight may not match a processor's calendar day or the accounting system's time zone. A difference is not automatically an error, but it needs an explanation and a repeatable way to trace activity across periods. Record the cutoff and time zone beside the mapping worksheet.
Also decide what happens when an account is missing or a transfer fails. Will the integration stop, place an amount in a holding account or require manual correction? Who receives an alert, who fixes the mapping and how is the corrected entry sent without duplicating the original? Ask for a visible error example and a recovery procedure.
For a safe simulation, use sample data or a vendor-provided test environment that cannot create a real card charge, guest message or courier dispatch. Compare the resulting report and entries with your expected worksheet. If the vendor cannot demonstrate a case safely, document the gap and agree on a manual review process rather than assuming it works.
A live service pilot is a separate decision. If you choose one, define the locations, dates, responsible reviewers and fallback process in advance. Review actual entries and settlements during that period; do not treat a simulation as proof that every live exception will behave the same way.
Choose a launch path and assign ownership
For a practical decision, suppose a vendor can map sales, tax and tips but cannot supply processor fees to accounting. If your processor provides a usable fee statement and your accountant agrees to a recurring manual entry, that may be workable. Assign a person and deadline, and confirm the clearing account can still be reconciled. If no one can reliably obtain or enter the fee, resolve that gap before launch rather than accepting a daily deposit that looks right.
Make acceptance criteria specific: the sample day balances, each required category lands in its agreed account, the refund can be traced and the payout clears as expected. Add an owner for reviewing failures and a schedule for checking the first live periods. Keep the POS report, processor statement and accounting entry available to the reviewer.
Request a Fleksa demo and bring your account list, sample reports, required mappings and refund test case. Ask the team to show which parts of your accounting workflow the proposed setup can support and which need another process.
Frequently asked questions
Does a matching bank deposit mean the accounting mapping is correct?
No. It confirms the deposit amount matches the item being compared, but sales, tax, tips and fees may still be combined or assigned to the wrong accounts. Check those categories against their source reports separately.
Should a refund appear on the original sale day?
That depends on the system's reporting and the treatment your accountant chooses. Ask how the refund date and original transaction are shown, then document how reviewers will trace the adjustment.
What if the integration cannot send processing fees?
Ask whether the processor provides a fee statement suitable for a manual entry. If so, assign someone to enter and review it. Include that work in the operating decision and confirm the resulting clearing balance with your accountant.
