Toast is common in food halls and brick concepts. Coordinators care about stall-level truth for percentage rent, not the POS brand.
MoneyLayer’s compatibility stance is pragmatic: connect where data access exists, structure everything else.
Percentage rent arguments are almost never about the POS UI—they are about whether everyone agrees what “gross” means after refunds, comps, and third-party delivery adjustments. Your integration page should not pretend Toast solves policy; it should make policy legible.
Connected where possible. Structured self-report where it isn't. Every number carries freshness, coverage, and provenance.
At-a-glance matrix
| Capability | Connected | Self-report |
|---|---|---|
| Connected Toast readsVaries widely by operator agreements and access. | Partial | Exports / manager attestation |
| Delivery aggregator sales | No | Usually manual reconciliation |
Setup
Organizer-side
- Separate ‘landlord settlement’ from ‘tenant POS’ mentally—different systems.
- Define whether percentage rent uses gross before refunds or a net policy after refunds.
Vendor-side
- If you are a tenant, ask what evidence the hall requires when Toast exports lag.
What data we pull
- Pilot-dependent connected reads where available.
- Otherwise structured totals with evidence.
What we cannot do with this POS
- MoneyLayer is not a Toast replacement; it is a coordinator-sidecar for revenue truth.
- Tenant-owned Toast configurations may restrict what exports a coordinator can see without operational agreements.
- Delivery platform economics can dwarf in-hall card totals—decide whether those dollars belong in the same reporting bucket.
FAQ
Do tenants have to leave Toast?
No. That would be the wrong trade for most halls.