Yes, an owner can distinguish a customer-facing packaging charge from food revenue if the marketplace, integration, and POS preserve enough detail—and if the marketplace statement provides a way to reconcile it. Do not assume that seeing the right order total means the charge is classified correctly. A $2 packaging charge can be included in the total while being combined with food sales in the POS.
Before signing or rolling out an integration, trace one sample order through the source order, POS record, and marketplace statement or statement preview. Ask what happens when a charge is separate at the source but cannot be mapped to a separate POS category. A clear answer may be a supported mapping, a documented manual workaround, or a reason to choose another setup.
Define what the packaging charge needs to do
Start with the charge the guest sees, not the restaurant's cost of buying containers. A customer-facing packaging fee is part of the guest's order. It is different from a marketplace commission, a payment processing fee, or a charge the restaurant pays a packaging supplier. Those amounts may appear elsewhere in a statement or expense report, but they answer different questions.
Decide whether the restaurant needs the packaging amount displayed as its own line on the order, reported in a separate POS category, or both. A separate line helps staff explain the total. A separate reporting category helps the owner compare food sales with packaging charges. One does not necessarily guarantee the other.
Write down the scope: location, marketplace, POS, order device, and any integration or middleware between them. Include the order types that matter, such as delivery and marketplace pickup, if both can carry the charge. Settings can differ by location or channel, so an answer for one combination should not be treated as proof for every combination.
The owner or operating manager should approve the reporting requirement. The person who closes out marketplace statements should help define the fields needed for reconciliation. The POS administrator can confirm whether the category and reports are usable in daily operations. Involve a qualified adviser when deciding how the charge should be treated for tax or accounting purposes; the software demonstration should show the available settings, not substitute for that advice.
Find where the charge starts and where it goes
Ask who creates the fee: the marketplace, the restaurant in marketplace settings, or another part of the ordering flow. Then ask whether the integration receives a distinct packaging amount or only an order total. If the source does not send a separate value, a POS mapping alone may not be enough to identify it downstream.
Follow the charge through three records:
- Source order: Is the packaging amount visible separately from food, delivery charges, and any tax?
- POS order and reports: Does the amount arrive as a named line, and can it be reported separately from food revenue?
- Marketplace statement: Is there an order-level amount or another reference that lets the team connect the charge to the order? If not, what reconciliation detail is available?
Also ask how the setup handles tax settings for the packaging charge, including which system controls them and whether a change passes through the integration. Have your qualified adviser determine the appropriate treatment. A vendor should demonstrate the settings and resulting records for your configuration rather than promise a universal outcome.
For each channel, ask what happens to a changed or canceled order. If a packaging charge is removed or refunded, can the team identify the adjustment in the POS and on the marketplace statement? Ask about missing fee fields, duplicate orders, and a marketplace order that cannot be matched to a POS order. Record a case as unsupported if it is outside the integration's scope; decide whether the restaurant can handle it rather than assuming every provider must support it.
Fleksa's integration directory distinguishes live connections from connections available on request. Availability depends on the restaurant's setup. When comparing a provider with an existing POS connection, ask each vendor to demonstrate the same location, marketplace, and POS combination. The guide to direct POS integration and middleware can help identify who is responsible for each handoff.
Trace a sample order without sending it live
Hypothetical example: A marketplace order contains $24 in food and a $2 customer-facing packaging charge, for a $26 guest total. This example excludes tax, delivery charges, discounts, tips, marketplace commissions, payment processing fees, and refunds. It describes an order total, not a payout or the restaurant's all-in operating cost.
Set the expected result before the demonstration: the source order shows $24 for food and $2 for packaging; the POS retains the $26 total and reports the $2 separately from food; and the marketplace record provides enough detail to match the charge to this order. If a statement does not show packaging by order, ask for the actual available report and decide whether it supports your closeout process.
Give the sample a unique identifier, such as PKG-042, and include a food modifier. Ask the vendor to use a sandbox, demonstration records, or another controlled simulation. The simulation must not charge a real card, send a guest message, or dispatch a courier. Match the identifier from the source order to the POS and kitchen result. Check that the modifier and total survive the handoff as well as the packaging line.
For the statement step, use a demonstration statement or a representative statement with sensitive information removed. A simulated order may not create a real marketplace settlement, so the vendor should show how the statement fields would be matched rather than imply a payout occurred. Check whether the reference is an order ID, date and amount, or another usable key. If multiple orders could share the same date and total, amount alone is a weak match.
Capture what you actually observe next to the expected result. For example, if the POS shows $26 but reports all $26 as food, the total passes while the classification fails. If the vendor cannot show the statement detail, mark that part unknown—not passed. Record who will obtain the missing evidence and by when.
After a successful simulation, a separately approved live service pilot can check normal operations using the restaurant's established controls. Agree on the channel, staff responsibilities, and stop conditions first. A simulation and a live pilot answer different questions; neither guarantees uninterrupted service.
Make the decision and assign exceptions
Use a short decision table for each marketplace and location. The examples below illustrate how to record outcomes; they are not results from an actual integration test. The owner should review failures and unknowns with the person responsible for statement closeout.
| Check | Illustrative outcome | Status | Follow-up |
|---|---|---|---|
| Source order | Food $24 and packaging $2 appear separately; total is $26. | Pass | Save the demonstration record and configuration. |
| POS classification | Total is $26, but the report combines packaging with food. | Fail | POS administrator asks whether a separate mapping is available and retests. |
| Marketplace statement match | Statement detail was not shown. | Unknown | Closeout owner requests a representative statement and matching instructions. |
| Cancellation adjustment | Handling of the packaging charge was not demonstrated. | Unknown | Vendor demonstrates the supported adjustment flow or documents its limit. |
In this example, do not approve the setup as meeting a requirement for separate POS reporting: the classification failed, even though the total was correct. If the vendor offers a configuration change, repeat the same sample and review the new POS report. A statement match remains an open item until someone can demonstrate it with the records the restaurant will actually receive.
A manual workaround may be acceptable for a low-volume channel, but describe it in operational terms. Who pulls the marketplace report? How often? How is the packaging amount kept separate when it is combined in the POS? Who checks discrepancies, and where is the work recorded? Estimate the staff time and any quoted setup or recurring charges before comparing options. Those costs are separate from the $26 sample order and from any processing fees.
Have the owner approve any exception in writing, with an end date or review date. Assign a retest after a configuration change, a new marketplace connection, or a change in statement format. Keep the source order, POS report, statement example, and vendor response together so the next person responsible for closeout can repeat the check.
Request a demo of the Fleksa restaurant POS with your sample scenario. Ask the team to show the order line, POS classification, and available reconciliation detail for your actual marketplace and location. Bring the person who handles closeout, along with any requirements your restaurant management software reports need to meet.
Frequently asked questions
Does a correct order total prove the packaging fee is mapped correctly?
No. The total can be correct while the POS combines the packaging charge with food. Check both the order line and the report category.
What if the marketplace statement does not list packaging by order?
Ask for the available statement and order-level reports, then determine whether they provide a reliable matching key. If they do not, document the manual reconciliation and have the owner approve the limitation.
Can I check a packaging fee without a live customer order?
Ask for a sandbox or controlled demonstration using a unique sample identifier. It should not create a real card charge, guest message, or courier dispatch. Review live operations separately if you later approve a service pilot.
