Syncing a Restaurant POS to Zoho Books: What I Built into Mealnix

Most restaurants I work with keep their numbers twice. Once in the POS, where every bill and every payment is already recorded to the rupee, and again in the accounting software, where someone re-types a day or a month of sales into a journal so the books can be closed and returns filed. The second copy is where the hours go, and where the mismatches come from.

So the newest thing in Mealnix, the restaurant billing platform I build and run, is a direct Zoho Books sync. Settle a bill in the POS and it lands in Zoho Books as an invoice with its payment already applied. No CSV, no month-end catch-up, no accountant asking for a login to a system they do not want to learn.

What the integration actually does

I kept the scope deliberately narrow, because accounting data should be boring:

• Paid orders become sales invoices. One bill, one invoice — nothing is summarised or rounded on the way across.
• Payments post with the invoice. The invoice never sits open waiting for a manual match, so receivables stay clean.
• Customers are created on demand. If the guest on the bill has no contact in Zoho Books, one is created before the invoice is posted.
• Menu items are created on demand. Dishes become real Zoho Books items with their rates, so item-level sales reporting works on the accounting side too.
• Taxes are mapped, not re-entered. The tax rates configured on the menu resolve to Zoho Books taxes, so a GST bill arrives as a GST invoice.

Everything is driven from one settings tab, and the whole connection is a five-minute job for the restaurant owner.

The parts that took the thinking

Data centres are not interchangeable

Zoho runs separate data centres — .in, .com, .eu, .com.au and others — and an OAuth client created in one will not authorise against another. The API domain, the accounts domain and the console all have to agree. This is the single most common reason a Zoho integration fails on first connect, and the failure message is not helpful about it. So the data centre is an explicit dropdown in the settings screen rather than something inferred, and every API base URL is derived from that one choice.

The redirect URI has to be exact

Zoho matches the callback string character for character. A trailing slash, or http where the console has https, and consent is rejected. Rather than document it and hope, the app shows the exact URI with a copy button next to it. Small thing; it removed most of the support messages.

Tokens, and the one that does not expire

Access tokens are short-lived, refresh tokens are not. The refresh token is issued once, at first consent, and if you lose it the owner has to go through the consent screen again. Handling that properly means storing it encrypted per tenant, refreshing ahead of expiry rather than reacting to a 401, and treating a revoked grant as a state the UI can show — hence Disconnect and Reconnect as separate actions, not one button.

Organisation selection is a real step

A Zoho login can hold several organisations, each with its own books and base currency. Guessing is not acceptable when the consequence is invoices posted into the wrong company. After OAuth, the app lists the organisations it can see, the owner picks one, and a Test connection call confirms read and write access before sync is switched on. The header then shows what it is connected to — Connected to The Canteen · INR — because a silent integration is one nobody trusts.

Posting has to be idempotent

Anything that talks to a third-party API over a restaurant's Wi-Fi will time out eventually, and a retry that creates a second invoice for the same bill is worse than no sync at all. Every order carries its own sync state, the Zoho document id is stored back against it, and a retry checks that before it posts. The counters in the settings header — Pending, Synced, Failed — are read straight off that state, alongside the last sync timestamp and a link into the full sync log.

Failures need a name

The useful thing in an integration like this is not the happy path, it is the log entry that says which bill failed and why — a tax rate that could not be mapped, a contact rejected for a malformed field, a rate limit hit during a dinner rush. Those sit in the sync log with the Zoho error attached, and they can be retried individually once the cause is fixed. A failed count that stays at zero is only meaningful when a non-zero count would have told you something.

Why it is worth doing at all

The obvious win is the typing that disappears. The less obvious ones matter more over a year:

• Month-end stops being an event. If the books are current every night, closing is a review instead of a data-entry sprint.
• The GST return matches the till. The most common cause of a mismatch between filed returns and actual sales is a person re-keying totals. Remove the re-keying and you remove the class of error.
• The accountant stays in their own tool. No POS login, no training, no monthly export to chase.
• Item-level numbers exist on both sides. Because dishes sync as real items, food cost can be compared against revenue per dish rather than estimated.

If you are building something similar

The API work is the easy half. What decides whether an integration is actually used is everything around it: making the data centre explicit, showing the callback URI instead of describing it, naming the organisation you are connected to, keeping a log that a non-technical owner can read, and making every write safe to repeat. A sync that quietly duplicates invoices, or quietly stops, costs more trust than it ever saved in typing.

If you need a POS, an ERP or an internal tool wired into accounting software — Zoho Books, Tally, QuickBooks or otherwise — tell me what the two systems are and I will tell you honestly what is straightforward and what is not.