Skip to content

Import a menu from a photo or a file

The two import doors, what each one can read, and why nothing reaches your catalog until you have looked at every row.

Updated 11 September 20264 minApplies to: Back office, Help centre

Two doors, and they do different jobs

Import menu from photo reads a picture of a printed menu card. It is a section of the Menu workspace, and it produces dishes and their categories.

Import menu, stock & customers reads a spreadsheet or a CSV. It handles four kinds of thing — your menu, your stock list, your customer book with what they owe, and last year's sales from an old till.

Neither one writes anything to your catalog until you have reviewed the rows and pressed approve.

From a photo

Take or upload a PNG, JPEG or WebP of the menu card. The clearer the print and the flatter the page, the more of it comes back.

What you get is a draft table, not a menu. Every row is editable in place — name, category, price, the veg mark — and any row can be removed before you approve. When you approve, each remaining row goes through exactly the same create path a hand-typed dish uses, so it inherits the same validation and the same audit trail.

Prices are copied, never calculated. The extraction is told to reproduce the printed price exactly, and the product then parses that text itself into an exact amount. Common Indian printings are understood, including the ones with a currency word in front or a trailing slash.

A price that cannot be read does not become a guess. The dish drops into a skipped list beside the draft, showing the text that was printed, with one of three reasons — no price on the card, a price that could not be read, or a negative one. You type it in yourself. A printed zero is accepted, because a free item is a real menu line.

Photo import needs the assistant to be switched on for your deployment and included in your plan, and it needs file storage configured. When any of those is missing the screen says which one rather than failing — and points you at adding the dish by hand, which always works.

What a photo import does not set: tax class, station routing and modifier groups. It brings in the name, the category, the price, the veg mark and the tax code where the card printed one. Finish the rest in the editor.

From a spreadsheet or a CSV

Before you start: save the file as .xlsx or CSV. The old .xls format is not read, and the screen will say so rather than half-reading it. Files are capped at five megabytes and five thousand rows.

The steps are the same for every lane:

  1. Drop the file. A spreadsheet is read in your own browser, not on our servers. If storage is configured, a copy of the file you uploaded is kept privately for audit; if it is not, the import runs anyway with nothing stored.
  2. Map the columns. Your headers are matched first against the column names common exports use, so a file straight out of another till usually arrives already mapped. Anything unmatched you set by hand from a list of the fields that lane accepts. Manual mapping is always available and always sufficient — the assistant's suggestion is an optional shortcut, it may only propose headers that actually exist in your file, and with the assistant unavailable the screen is fully usable.
  3. Read the review grid. Every row is marked: it will be created, it will update something that already exists, it is a duplicate that will be skipped, or it is invalid with the field and the reason named.
  4. Commit. Rows go in batches. A bad row costs itself and nothing else — the rest of the batch still lands, and the grid keeps the failures so you can fix and re-commit just those.

Re-committing the same batch does not double anything. Each row carries an identifier derived from the batch and its position, so a retry after a timeout, a second click, or a replay all recognise the row that already landed and return it rather than making a second one.

If you do not have a file to start from, each lane offers a blank template with the right headers and one worked example row.

What is not a shortcut

Two limits are deliberate, and knowing them saves an argument with the numbers later.

Old sales stay separate. Sales imported from a previous till are held as their own series. They are never billed, never taxed, never given a bill number, and they never enter your GST returns, your books or your banked figure. They appear as a labelled overlay on the trends report so you can compare years, and nowhere else. Re-billing old sales would be wrong, and it is out of scope permanently.

Opening balances are not sales. What a customer owed you before this product existed is recorded as an opening balance against that customer, not as a credit sale. Their outstanding is then what they owed plus what they have since charged, minus what they have repaid.

The stock lane needs the inventory module switched on, because raw materials and recipe links are inventory writes. The menu, customer and sales lanes work for every business.

Still stuck?

Beta