An accounting export can reconcile restaurant sales, taxes, tips and payment movements only if it includes enough detail to connect each transaction to the reports and settlement records behind it. A daily sales total alone is not enough. Your accountant needs to see what was sold, what was collected, how it was paid and how later adjustments are recorded.
Before choosing a POS, ask for a sample export and walk it through a reconciliation with your accountant. The goal is to check whether the source data is complete and understandable. Deciding which accounting accounts receive those amounts is a separate step.
Ask your accountant which fields are needed
Start with the reports your restaurant already uses and the questions that are hard to answer at month-end. A single-location counter-service restaurant may need a simpler export than a group with several locations, delivery channels and multiple payment providers.
Ask your accountant to mark each field as required, useful or unnecessary for your workflow. Include the person who closes the register and anyone who checks payment deposits. They know where discrepancies tend to surface.
| Field group | Examples to request | What it helps reconcile |
|---|---|---|
| Transaction identity | Transaction date and time, order ID, receipt or reference number, location ID | Individual orders, reporting periods and locations |
| Sales and adjustments | Item or category, sales amount, discounts, voids, refunds and original transaction reference | Sales reports and changes to earlier transactions |
| Tax and tips | Tax amount and category, tip amount, service charge identified separately | Amounts collected beyond sales and their separate treatment |
| Payment movement | Tender type, payment amount, payment reference, fee, settlement date and payout reference where available | Cash, card activity and deposits or settlement records |
The groups work together. An order ID identifies the sale, but a payment reference may be needed to match its card payment to a processor record. A refund needs enough detail to find the original sale and see when the money moved. Ask whether those references appear in the same file or must be joined across reports.
Also ask how split tenders appear. If a guest pays part in cash and part by card, can the export show both payments without counting the sale twice? Check gift cards too: can the records distinguish a gift card sale from its later redemption? Your accountant can explain which details are needed for your restaurant’s treatment.
Other useful fields may include order channel, employee or register identifier, and separate amounts for delivery charges or other fees. Do not assume that a field named “total” includes the same components in every report. Ask for definitions before deciding it meets the requirement.
Inspect an export, not just a feature list
Request a representative sample in the format you expect to use. A spreadsheet-friendly file may suit a manual workflow; an integration may send data differently. In either case, ask for a field list and a description of what each row represents: an order, an item, a payment, an adjustment or a daily summary.
That distinction matters when adding the file. An order-level total repeated on every item row can inflate sales if someone sums the column. A separate payment row can create a similar problem if it is treated as another sale. Ask the provider how its sample should be totaled and which identifier connects related rows.
Check these details with your accountant:
- Dates: Is the date based on the order, payment, refund, business day or settlement? Can a late-night transaction fall into a different reporting day?
- Amounts: Are refunds negative? Are discounts already deducted? Are tips and taxes included in a total or listed in addition to it?
- Currency and locations: Is currency identified, and does each row carry a location identifier that matches the restaurant’s records?
- Detail: Can you see the separate tenders and adjustments behind a daily total, or only the aggregate?
- Access: Who can run the export, how often can it be produced, and can the same historical period be retrieved later?
Ask how the file handles corrections made after the original business day. A refund processed on Tuesday for a Sunday sale may appear in Tuesday’s activity, against Sunday’s order, or in another report. The important thing is that the workflow makes both the original transaction and the later movement traceable.
If you are considering a connection to accounting software, inspect that workflow separately from a downloaded file. Ask what data is transferred, at what level of detail, how errors are reported and what happens if a transfer fails. A connection that posts a daily summary may be useful, but it does not automatically replace transaction-level records. Review the available restaurant integrations and bring specific integration questions to the provider.
Reconcile a small sample period
Use the same business period, location and currency across the export and POS report. Then compare payment activity with the relevant processor settlement records and cash records. Settlement dates can differ from transaction dates, so match references and periods before treating a difference as an error.
Hypothetical example: A restaurant has $100 in sales after discounts, $8 in tax and $12 in tips. Guests pay the $120 collected with $90 by card and $30 in cash. The card processor deducts a $3 variable processing fee and settles $87. There are no refunds or other exceptions in this sample.
First, check the POS export against the sales report: $100 in sales plus $8 in tax plus $12 in tips equals $120 collected. Next, check the tender detail: $90 in card payments plus $30 in cash also equals $120. Finally, compare the card activity with the settlement record: $90 less the $3 fee equals the $87 payout. The cash amount remains separate; it is not part of the card payout.
The $3 is a processing fee, not a reduction in sales or a guest tip. This example includes that variable fee. It excludes fixed software or equipment costs and has no exception costs. The payout is a payment movement, not the restaurant’s total sales or all-in operating cost.
If the export shows only the $87 payout, it does not by itself explain the $90 in card activity and the $3 fee. Ask whether another report supplies the missing detail and whether a payment or payout reference links the records. If the $30 cash appears in the sales report but not the tender export, find out how cash is documented before signing.
Then inspect separate cases for a refund, a void, a split payment and a transaction spanning two business days. These are checks of sample records or a simulation, not instructions to run live orders. A simulation should not trigger a real card payment, guest message or courier dispatch. For any later live service pilot, agree on safeguards and responsibilities with the provider and staff first.
For each case, write down the expected records and the actual sample fields. A refund check, for example, should identify the original sale, the refund amount and date, and the related payment movement where applicable. If those pieces live in different reports, confirm that the references allow someone to join them without guessing.
Resolve gaps before you choose
A missing field does not always rule out a POS. It does change the work needed to close the books. Ask whether the information is available in another export, a processor report or a separate workflow. Then identify who will retrieve it, how often and how they will match it to the POS data.
For example, if payment fees appear only on the processor statement, your accountant may be comfortable entering them from that statement. If the statement cannot be matched to the POS period or payout reference, the workaround may take more investigation. Have the people doing the work review a sample rather than assuming the extra report solves the problem.
Record each gap in a short decision log: required field, available source, matching reference, owner and unresolved question. Ask the provider to demonstrate the intended export or connection for your locations and channels. Confirm whether the sample reflects the configuration you would buy and whether any extra service or setup is needed. Get those terms in writing; ask a qualified adviser about contract or tax treatment when needed.
For a smaller operation with a manageable number of transactions, a documented manual match may be acceptable. For several locations with frequent adjustments, the same manual work may be a poor fit. Choose based on the actual records, staff time and quote, not on the presence of an “accounting export” label. For a broader look at connection choices, see the related buying guide.
Next, send your field checklist and one sample reconciliation to a POS provider. Ask them to show where each required value and reference appears. You can discuss the workflow with Fleksa when evaluating its restaurant POS.
Frequently asked questions
Is a daily sales summary enough for accounting?
It may be enough for part of a workflow, but it may not explain individual refunds, split tenders or payment settlements. Ask your accountant which supporting transaction records are needed alongside the summary.
Should tips be included in sales?
The export should identify tips separately so your accountant can determine their treatment. Check whether the POS total includes tips and whether payment reports show how they were collected.
Why does a card payout differ from card payments?
Fees, refunds, settlement timing or other adjustments can create a difference. Compare payment references and settlement records before assigning the difference to a cause.
