Restaurant invoicing: receipts, tax invoices, and marketplace settlements

Separate the guest receipt, tax invoice, marketplace service invoice, and settlement, then reconcile each document to orders and bank deposits.

Start with the document and its issuer

Restaurant invoicing involves several documents that can refer to the same meal without representing the same transaction. A kitchen ticket tells staff what to prepare. A payment receipt confirms a charge. A tax invoice documents a sale under a jurisdiction's rules. A marketplace service invoice concerns the platform's charges to the merchant. A settlement explains how collections and adjustments become a transfer.

Give each document an owner, recipient, identifier, and relationship to the order. This prevents two common errors: treating the bank deposit as total restaurant sales, and assuming that an invoice for marketplace commissions is the guest's meal invoice.

Keep four relationships separate

  • Restaurant to guest: the food sale, with the applicable receipt or tax invoice and a path for corrections.
  • Marketplace or service provider to restaurant: platform commissions or other contracted services, issued by the entity in the merchant agreement.
  • Operator to merchant: charges or balances arising from the marketplace's own operating model. A payout statement and an invoice are not automatically interchangeable.
  • Operator and driver: delivery charges, earnings summaries, and payment records, with the document's direction determined by the actual contract and local rules.

The party collecting money is not always the party issuing every invoice. Record the legal entities and the document type rather than deciding from the logo shown at checkout.

Use the country's invoice rules

In Mexico, the SAT's CFDI 4.0 recipient-data guidance identifies the RFC, registered name, fiscal postal code, fiscal regime, and intended invoice use. Collect the fields through the approved invoicing flow, with access limited to the people who need them. An order PDF with a logo does not establish that a valid CFDI was issued.

In the United Kingdom, GOV.UK's invoice guidance distinguishes invoice identifiers, supplier and customer details, supply and invoice dates, amounts, and VAT where applicable. A Mexico-specific CFDI workflow does not substitute for those requirements.

The implementation needs a country-specific decision about the issuer, required data, issuance system, corrections, and record retention. Have the responsible finance or tax team approve that design; a generic ordering configuration cannot determine it for every market.

Distinguish Uber Eats billing from the guest's invoice

For a restaurant in Mexico researching Uber Eats invoicing, the relevant merchant document can be the invoice for Uber Eats service commissions, not the customer's food invoice. Uber's merchant tax-data article describes that service-invoice relationship. Match the issuing entity, restaurant tax data, service period, and agreement before recording it.

Use the marketplace reports for reconciliation. Uber's payout-summary documentation distinguishes aggregate transfers from order-level details and uses a payout reference to relate reports. A transfer can combine many orders and adjustments; one invoice number alone may not explain it.

For a guest requesting a meal invoice, route the request to the issuer responsible for that sale in the relevant country. Do not send the restaurant's commission invoice as a substitute or expose another customer's fiscal information.

Reconcile a transfer without hiding the deductions

Take a simplified, illustrative period in one currency, with tax treatment deliberately excluded from the arithmetic:

  • Customer order collections: 1,000.
  • Refunded collections: 50.
  • Contracted service charges withheld: 150.
  • Expected transfer: 1,000 − 50 − 150 = 800.

The 150 is an example amount, not an Uber Eats commission rate. The restaurant needs the underlying orders, refund references, provider invoice or charge detail, and payout reference to explain the 800. Posting only 800 as sales hides the original activity.

In a real close, add the separate lines that actually apply: tax collected or withheld, funded promotions, delivery charges, tips, disputed payments, and adjustments from other periods. The finance team determines their accounting treatment. Keep a timing difference open until the corresponding statement or deposit arrives, rather than inventing a balancing sale.

Connect ordering records to the approved invoicing system

Ordering.co's invoicing and billing manager covers invoices for stores and drivers, their charges, branding, and payment status. That operational scope does not establish country-specific fiscal certification, statutory bookkeeping, or automatic submission to a tax authority.

For an integration, map order ID, legal entity, location, currency, tax and discount detail, payment/refund references, and invoice status. Define what happens when issuance fails, a paid order is canceled, or the customer corrects fiscal data. A repeated event must not create a second fiscal document for the same intended issuance.

Before rollout, complete a sale, a correction, a refund, and a marketplace settlement using the actual country configuration. The operator should be able to navigate from order to payment, invoice, adjustment, and bank deposit, with an owner for every exception. Continue with the restaurant accounting and ERP workflow when the question concerns ledgers and financial close rather than document issuance.

See it running on your own menu.

The shortest way to understand any of this is to watch an order go from a storefront to a store to a driver, on your locations.

What are you building?

Tell us and we’ll take you to the right next step.