A single jobcard can produce several different documents depending on who's reading them. They all share the same data underneath but the formatting differs: a technician needs the work, a customer needs the cost, a fitter signing off an inspection needs the checklist.
The four types
Customer-facing jobcard / estimate
Shown when you print or share a jobcard with the customer before invoicing. Includes garage branding, customer name, vehicle, the full list of jobs with their parts and labour, and the cost breakdown with VAT. For: the customer.
Invoice
The same shape as the customer-facing jobcard but framed as a billable document — invoice number, due date, payment status, and your bank or payment instructions. Issued from the jobcard once the work is done. For: the customer (for payment) and your records.
Technician work order / job sheet
A stripped-down printout for the workshop floor. Registration, make/model, mileage, jobs, parts, labour. No customer name. No contact. No dates. See the PII rule for why. For: the technician doing the work.
Inspection report
Generated from an inspection submission linked to the jobcard. Shows the checklist results, condition ratings, photos, and any signature captured. The customer-facing variant carries garage branding and vehicle details; the internal variant is for your records. For: the customer, plus an internal copy in your records.
Same data, different lens
Every document is generated from the live jobcard — change the labour rate on a job and the next print reflects it. The difference between document types is which fields are shown, not which fields exist.
Server-side filtering of financial fields
Users without payments.view get a jobcard payload from the API that already has rates, prices and unit costs removed. So a technician who somehow ended up viewing a jobcard JSON couldn't print a customer-style document by accident — the data isn't there to print.