A millimetre
is a wasted cheque.

UAE businesses still issue large volumes of cheques — for rent, suppliers, payroll advances and post-dated instruments. Most write them by hand or fight with a template in Word that was aligned once, on one machine, by someone who has since left.

The failure mode is specific and expensive. A printer driver silently substitutes A4 when it can't honour a custom paper size. The cheque feeds skewed, the payee lands across the amount box, and a numbered leaf is destroyed. Worse, an alignment that worked yesterday stops working after a driver update or a power cycle, because the offset was never stored anywhere durable.

And every bank's cheque is a different size with fields in different places. Any solution that hard-codes one layout is obsolete the moment the business opens a second account.

Everything is expressed in millimetres, not pixels. A cheque layout is a physical width and height plus a set of fields at real-world X/Y coordinates. Rendering computes back to device units at print time, which is what makes the output identical across printers with different DPI.

Alignment is stored per printer. Each printer keeps its own offset, so switching from the office laser to the one upstairs is a dropdown, not a re-calibration. The offsets survive restarts and driver updates because they live in application storage, not in a document.

Mapping a new bank has two paths, because two different kinds of user exist. Upload a scan of the cheque and drag each field onto it; or, with no scanner available, print a numbered millimetre grid at the exact cheque size, lay a real cheque against it, read the coordinates off, and type them in. The editor shows the same numbered rulers, so what is measured is what prints.

The magnetic MICR band at the foot of the cheque is marked as a permanent no-go zone in the editor. Printing into it can render a cheque unreadable to bank clearing equipment, so the interface makes that mistake visibly impossible rather than documenting it in a manual.

1. Detecting a printer that will silently lie Many drivers accept a custom paper size and then quietly fall back to A4 — which is exactly the failure that eats cheque leaves. Precheque detects the fallback before printing and shows a blocking warning naming the printer. Virtual printers that can never do custom sizes are called out explicitly.
2. Amount-in-words that a bank will accept Converting a numeric amount to written words is deceptively fiddly: fils handling, hundreds-and-tens joining, and the "only" terminator convention. It has to be right every time, because a mismatch between figures and words is a returned cheque.
3. Batch printing without blank pages Naively printing many documents produces stray blank sheets — which, in a loaded cheque tray, means consuming and voiding real cheques. The batch engine emits exactly one page per cheque in a single job so a stack feeds cleanly in one pass.
4. Validating a spreadsheet a human filled in Batch input arrives as Excel edited by a person. Rows are parsed, validated, and shown in a review table with invalid rows flagged and skipped rather than silently printed wrong — the last checkpoint before consuming physical stock.

Cheque runs that took an afternoon of hand-writing take one pass through a printer. Alignment stays correct across restarts, driver updates and printer changes. Payee names autocomplete from history, and every printed cheque is logged.

Adding a bank is a task for the person who uses the software, not a support ticket — which means the product is not tied to the specific set of banks it shipped with, and does not require us to be in the loop for it to keep working.