Payment, Collection and Payout Terms

This English page is a support translation. The Turkish legal text prevails in case of inconsistency.

Scope: Türkiye; B2B corporate meal service; EFT/bank transfer collection; weekly (Monday-Sunday) reconciliation period; an invoice that may cover one or more completed weekly reconciliations; Buyer payment due within 5 days at the latest after the invoice date; Seller net payout within 5 days at the latest after the Buyer collection reaches the collection channel and reconciliation is complete. This annex takes effect together with the AHS, the Buyer Platform Terms and the active link / transaction record.

Parties: POİEX TEKNOLOJİ LİMİTED ŞİRKETİ / iştebu!, the Seller and the Buyer.
Scope: EFT / bank transfer only. Out-of-scope payment and financing products are listed in a single place in Section 1.
Invoice chain: The Seller issues a meal service invoice to the Buyer. iştebu! issues an intermediation / platform / coordination service invoice to the Seller. iştebu! is not a meal service seller, principal or reseller.
Payout principle: If the Buyer collection has reached the collection channel and reconciliation is complete, the net payout is paid within 5 days at the latest from collection.

1. Purpose and Scope

This annex governs, for the Buyer-Seller matches formed through the iştebu! platform, the payment of the meal service amount by EFT / bank transfer to the iştebu! collection channel, the closing of the Buyer’s debt under the relevant Seller invoice by that payment, the set-off by iştebu! of its intermediation fee and contractual adjustments, and the payment of the remaining net payout to the Seller.

Scope: B2B corporate breakfast, lunch, snack and dinner services, the Buyer-Seller active link, the AHS model in which the Seller invoices the Buyer, EFT / bank transfer collection, the weekly (Monday-Sunday) service period, the Buyer payment term of within 5 days of the invoice and the net payout value date of within 5 days from collection.
Out of scope: credit card, virtual POS, payment link, PSP split, sub-merchant payout, beneficiary wallet / balance, meal card, customer funds, escrow, pooled account, financing, factoring, deposit, advance payment and resale / principal meal sale.
This annex does not make iştebu! a food service provider, meal seller, payment institution or financing provider.

Law no. 6493 commercial representative exemption: iştebu! is the commercial representative of the Seller (seller/creditor) within the meaning of Article 12 of Law no. 6493 and collects only on behalf of a single party (the Seller); this collection falls within the payment service exemption. The model is established as a contractual collection authority and a net payout debt with a due date. iştebu! does not offer a payment account, electronic money, wallet, balance, payment instrument, money transfer, escrow or customer funds product; the collected amount is held in a monitoring account.

2. Definitions

Unless expressly stated otherwise in this annex, the definitions in the AHS apply. Key terms for this annex:

Active Link / Transaction Record: The platform record binding the Seller, Buyer, location, period, price, deadline, delivery and contract versions.
Collection Authority: The contractual authority by which the Seller agrees, limited to platform transactions, that the Buyer’s payment is made to the iştebu! collection channel.
Collection Channel: The bank account, IBAN, reference code or bank reconciliation infrastructure notified by iştebu!
iştebu! Service Invoice Gross Amount: The gross iştebu! service invoice amount formed in the platform price snapshot and set off against the payout. In the company-facing meal price this charge is carried in the 10% VAT flow of the Seller’s meal service invoice; the service invoice that iştebu! issues to the Seller is reported by breaking out the same gross amount with 20% VAT included.
Per-Person Payout Anchor (VAT Included): The VAT-included per-person amount the Seller targets in a live menu price tier. Entries made through the meal amount excluding VAT or the Buyer total are normalized to this anchor. If the active link has a contractual discount, it is applied to the anchor first; the result is the Seller’s per-person payout in the assignment snapshot.
Net Payout: The amount payable to the Seller after deducting, from the collected amount matched to the period, the iştebu! service invoice gross amount, credit / adjustment / SLA deductions, holds and current-account adjustments.
Platform Records: Active link, acceptance, deadline, headcount, delivery, complaint, document, collection, invoice and payout report records.

3. Collection and Settlement of the Debt

By accepting the AHS and this annex, the Seller appoints iştebu! as collection agent solely for the Buyer meal service amounts arising through the iştebu! platform. This authority is not a general money-collection or payment-service authority; it is limited to the Buyer, Seller, location, service period and invoice scope bound by the active link / transaction record.

By accepting the Buyer Platform Terms, the active link / transaction record and this annex, the Buyer agrees to pay the meal service invoice issued by the Seller to the Buyer by EFT / bank transfer to the collection channel notified by iştebu! A payment made by the Buyer to the iştebu! collection channel and matched to the relevant invoice / period closes, to the extent of that amount, the Buyer’s meal service debt to the relevant Seller.

Each service week is completed as a separate reconciliation. The Seller may select one or more completed weekly reconciliations for the same Buyer and combine them in one invoice; the covered weeks, billable meal count and total amount are shown in the platform. The Buyer checks the relevant Seller invoice, headcount reports, delivery records and any credit / adjustment records; it pays the payment debt by EFT / bank transfer to the collection channel within 5 days at the latest after the invoice date.

Payment is made only to the collection channel notified by iştebu!
After the bank transfer, a Buyer admin may report the payment date and an optional PDF/image receipt through the platform. This declaration does not replace the bank record, discharge the debt, treat the reconciliation as collected, or start the Seller payout. Collection becomes final only after iştebu! operations confirms it against bank evidence.
A payment declaration that does not match the bank record may be rejected with the actor, time, and reason recorded; the prior declaration remains in the audit record and the Buyer may report again.
The payment description uses the reference code provided by iştebu!, the Buyer name, the Seller name, the service week and the invoice number, or other codes required for matching.
The Buyer may not exclude from late-payment risk any matching delay caused by bank charges, a missing description, an incorrect reference or payment to the wrong account.
If the Buyer wishes to pay directly to the Seller’s account, this transaction is not deemed compliant with the collection and payout flow under this annex unless approved in writing in advance by iştebu!
For invoices subject to withholding, the Buyer’s payment description must contain information sufficient to match the invoice gross amount, the withholding amount and the net cash amount paid to the iştebu! collection channel.
Incorrect / partial / excess / duplicate payment: an incorrect reference is treated as open until the payment is matched and the Buyer sends a corrective description; a partial payment closes the debt only to the extent of the matched amount, the remainder stays open; an excess or duplicate payment is set off against the next period or refunded and tracked in the current account.

This collection authority does not allow iştebu! to make general collections on behalf of the Buyer or the Seller. Receivables arising outside the active link, off-platform work, credit card / virtual POS flows, third-party collections and direct Seller payments fall outside this annex.

The amount iştebu! receives from the Buyer is not meal service revenue. The revenue of iştebu! is the intermediation / service fee invoice it issues to the Seller. The amount coming from the Buyer is, within the scope of the collection authority and the payout reconciliation, tracked as a payout debt / current-account obligation to the relevant Seller.

4. Net Payout and Payment

iştebu! pays the Seller’s net payout to the Seller’s registered bank account within 5 days at the latest after the Buyer payment reaches the collection channel and reconciliation is complete, if all of the following conditions are met. This period is consistent with the maximum period prescribed for payment to the Seller under Law no. 6563 and the electronic commerce intermediary service provider regulation, once the amount comes under the control of iştebu! and the service has been delivered:

The Buyer payment has reached the iştebu! collection channel and has been matched to the relevant invoice / service week / active link record.
The meal service invoice issued by the Seller to the Buyer is consistent with the platform records.
The headcount, bulk order, deadline, delivery and acceptance records have been taken into the weekly reconciliation.
The iştebu! service invoice gross amount and the related invoicing information have been finalized.
The credit / adjustment / SLA deductions, any food safety hold and current- account adjustments have been calculated.
The Seller’s bank information, tax information are in order and there is no open legal / operational hold preventing the Seller from receiving the payout.
The objection period for the payout report has been completed or objections have been resolved.

Net Payout =
  Collected Meal Service Amount Matched to the Period
- iştebu! Service Invoice Gross Amount
- Approved Credit / Adjustment / SLA Deductions
- Any Food Safety or Critical Incident Hold
- Any Prior-Period Current-Account Adjustments
- Any Bank / Transfer Charges Expressly Agreed in the Contract
+ Any Approved Adjustments in the Seller's Favor

The Seller net payout depends on the Buyer collection; no unconditional payment obligation arises for iştebu! before the Buyer payment reaches the collection channel. If the Buyer payment arrives late, the payout is still paid within 5 days at the latest after the collection has arrived and reconciliation is complete; it may be paid on the first batch payment day within that maximum period.

No payment guarantee: This annex does not mean that iştebu! extends credit to the Buyer, guarantees the Buyer’s debt to the Seller, or will make payment from its own resources unconditionally before the Buyer payment arrives.

5. iştebu! Service Fee, Adjustment and Hold

The iştebu! service fee is documented by a separate VAT-bearing service invoice issued to the Seller. iştebu! may set off the receivable arising from this invoice against the Seller payout calculated according to the platform records.

Missing portions, wrong menu, wrong label, quality problems, late delivery, failure to serve or a food safety incident caused by the Seller’s fault are deducted from the Seller payout.
Platform headcount, reporting or a commercial gesture originating from iştebu! remains with iştebu!; where there is no Seller fault, it is not deducted from the Seller payout.
A unilateral post-deadline reduction or cancellation request by the Buyer does not eliminate the invoicing of the locked headcount and the Seller payout unless accepted by the Seller and iştebu!
In case of a food safety suspicion, the default hold is only the amount of the relevant day / location / incident; in a serious or widespread incident a broader temporary hold may be applied by management decision.
The Seller must submit evidence or an objection on the same day for critical incidents; within 1 business day at the latest for ordinary credit / adjustment requests; and within 3 business days from sharing of the report for weekly payout report objections.
If the Seller does not submit concrete counter-evidence in time, iştebu! may decide based on the platform records, Buyer admin confirmation, photos, delivery time and multiple-complaint records.
“Penalty” language is not used in the payout report; the relevant lines are shown as “credit”, “adjustment”, “SLA deduction”, “hold” or “current-account adjustment”.

Campaign, discount, coupon, advertising and promotion costs are outside the scope of this annex. If opened in the future, a separate campaign annex or an electronic campaign approval is required; this annex alone does not grant authority to pass through campaign costs.

6. Late Payment and Suspension

Time	Action	Payout effect
Invoice +6 days	A written late-payment notice is sent to the Buyer; the Seller is informed; the receipt, payment date or a reconciliation objection is requested.	No unconditional payment obligation arises before the Buyer collection arrives.
Invoice +8 days	New menu assignments, new selection flows or new active link transactions are suspended. Continuation of existing service is subject to management approval.	For the unpaid period the net payout is deferred until the Buyer collection and reconciliation are complete.
When payment arrives	The payment reference is matched; the late-payment record is closed; the Buyer and the Seller are informed.	The net payout is paid within 5 days at the latest from collection or on the first batch payment day within that period.

If the Buyer bases the delay on an invoice, headcount or quality objection, the objection is assessed only to the extent of concrete records and evidence submitted within the time limit. The payment obligation continues for the part that is not objected to or that has been agreed.

7. Withholding and Reporting

Tax and invoice records are kept according to the following invoice model. The Seller issues a meal service invoice to the Buyer; iştebu! issues an intermediation / service fee invoice to the Seller. The payout report separately shows the invoice gross, VAT, any withholding, the net cash arriving in the iştebu! account, the iştebu! service invoice gross set-off amount and the net payout payable to the Seller.

A Buyer admin declares either “I am a designated buyer” or “I am not a designated buyer” in the invoice profile and must consult its tax adviser if uncertain. Existing and new profiles start as “not designated.” The declaration applies only to reconciliations that have not yet been invoiced; an issued invoice’s withholding, collection, and payout snapshot is not later rewritten.

For food invoices dated in 2026, the threshold is the VAT-inclusive total of the completed weeks selected by the Seller for one invoice. If the Buyer is designated and this total exceeds TRY 12,000, 5/10 VAT withholding and e-invoice code 604 apply to the food service; no withholding applies when the total is TRY 12,000 or below. The invoice gross does not change. The Buyer pays the iştebu! collection channel invoice gross - withheld VAT and declares/pays the withheld VAT through VAT 2. The Seller’s cash payout is reduced by the allocated withheld VAT; the iştebu! service invoice and other contractual set-offs continue under their existing rules. The platform blocks a withholding invoice until the threshold for a new tax year is configured.

Per-person prices are calculated to two decimal places using half-up rounding. Let H be the VAT-included per-person payout after any contractual discount and r the effective PHB rate for the transaction:

PHB gross                         = cents(H × r)
Buyer total including VAT         = H + PHB gross
Meal amount excluding VAT         = cents(H / 1.10)
Meal VAT                          = H - Meal amount excluding VAT
Buyer invoice total excluding VAT = cents(Buyer total / 1.10)
Company-flow PHB net              = Buyer invoice net - Meal amount excluding VAT
Company-flow PHB VAT              = PHB gross - Company-flow PHB net
iştebu! service invoice net        = cents(PHB gross / 1.20)
iştebu! service invoice VAT        = PHB gross - iştebu! service invoice net

The payout anchor is authoritative: any cent residual in VAT and fee sub-lines is assigned to those derived lines, so the entered payout is not reduced by one cent. For example, if H = TRY 215.00 and r = 10%, PHB gross is TRY 21.50, the Buyer total is TRY 236.50, and the Seller payout remains TRY 215.00. A Buyer-total entry is normalized, at the current PHB rate, to the nearest representable payout anchor; all three calculated amounts are shown before save.

A later PHB-rate change recalculates only live quotes that have not been snapshotted. The payout, effective PHB, Buyer total, VAT/fee components, and formula version frozen with a menu assignment are not changed retroactively. This cent reconciliation does not change the nominal PHB rate or prior records.

On the Seller → Buyer meal service invoice, 10% VAT applies. To keep the Seller’s accounting simple, the company-facing price also carries the service fee charge in this meal service invoice flow. If the Buyer is within the designated-buyer and annual-threshold conditions above are met, 5/10 VAT withholding applies for meal service and organization service; otherwise the flow is without withholding.
On the iştebu! → Seller intermediation / service fee invoice, 20% VAT applies; there is no default VAT withholding on the service fee invoice issued to the Seller. The invoice gross is the iştebu! service invoice gross amount in the snapshot; the 20% VAT is broken out within this gross amount.
Because of this structure, the service fee rate is not the effective VAT-exclusive revenue rate of the iştebu! service. For example, at a nominal 10% service fee rate, when the company-facing 10% VAT charge and the 20% VAT service invoice issued by iştebu! are read together, the effective VAT-exclusive iştebu! service revenue is approximately 9.17%; at a nominal 5% rate it is approximately 4.58%.
For company customers subject to withholding, the payout report does not mix the VAT amount that the Buyer is responsible for declaring / paying to the tax office with the net cash actually arriving in the iştebu! account.

8. Evidence Records

The following records are kept as the primary evidence set in collection, debt settlement, payout and dispute resolution:

The accepted contract versions for the Buyer, the Seller and iştebu!, the authorized-user information, the time of acceptance, IP / device information and the active link / transaction record.
The Seller, Buyer, location, service period, menu snapshot, price, delivery time, deadline and SLA records.
Beneficiary selections, Buyer admin bulk order records, headcount calculations and post-deadline lock records.
Delivery, acceptance, missing / wrong / late service, quality, food safety, photo / document, Buyer admin confirmation and Seller response records.
The meal service invoice issued by the Seller to the Buyer: e-invoice / e-archive number, date, gross amount, VAT, any withholding information and the net cash collection expectation.
The intermediation / service fee invoice issued by iştebu! to the Seller: the iştebu! service fee base, rate, VAT-exclusive amount, VAT amount, VAT-inclusive gross amount, invoice date and set-off reference.
The Buyer EFT / bank transfer receipt, bank statement, virtual IBAN or reference code, payment date, description and matching record.
The payout report: the collected amount, the iştebu! service fee, the service fee VAT, the credit / adjustment / SLA deductions, holds, prior-period current-account adjustments, the net payout, the target payment date and the actual payment date.
The +6 late-payment notice, the +8 suspension decision, Buyer / Seller notifications and records of the flow being reopened.
Payout objections, responses, management decisions and closing records.

Platform records must be kept with an immutable audit trail; manual changes must be recorded with the old value, the new value, the user who made the change, the timestamp and the reason.

9. Acceptance and Versioning

The method of acceptance of this annex is authorized platform acceptance. Acceptance is established when the authorized user approves on the platform the version of the relevant AHS, the Buyer Platform Terms, the payment instruction, the active link / transaction record and this annex.

The Seller accepts the AHS and this annex through an authorized platform user.
The Buyer accepts the platform terms of use, the payment instruction / debt settlement acceptance and this annex through an authorized platform user.
Each active link / transaction record shows the relevant Seller, Buyer, location, service period, price, SLA, invoicing term, collection channel and accepted contract versions.
The authorized user declares the authority to accept on behalf of the Buyer or the Seller; the evidence of authority is supported by the trade registry, signature circular, power of attorney, Buyer email domain or customer onboarding documents.
New versions do not retroactively change the prior-period payout base, the iştebu! service fee rate or the payment term; such changes require separate express acceptance.

The following material changes require separate acceptance and are applied with a new version:

Field	Control
Economic term	The iştebu! service fee rate, payment term, payout formula, withholding application, payment channel, debt-settlement language, the direct-Seller-payment fallback and the card / virtual POS / PSP model.
Operational updates	The credit / adjustment evidence standard, report format, bank reference field or notification channel may be updated with reasonable notice; they cannot retroactively change the prior payout base.