BillOS v1
Console llms.txt OpenAPI

The document lifecycle

create business (once per end user)
   └─ create draft ──> PATCH / DELETE freely (a draft is a "קובץ זמני", not a tax document)
         └─ issue ──> IMMUTABLE forever. Number assigned. PDF rendered + digitally signed.
               ├─ prints: origin (מקור): downloadable ONCE ever; then copies (העתק)
               └─ corrections: ONLY by issuing a credit note (or negative receipt)

Two rules Israeli law imposes, which the API enforces:

  1. Issued documents can never be edited or deleted, not by you and not by us (blocked at the database engine). Mistakes are corrected by issuing a credit note (חשבונית מס זיכוי) linked to the original, or for receipts a negative receipt. Plan your UX accordingly: confirm before issue.
  2. The origin (מקור) is delivered exactly once (הוראה 18(ב)2). The first prints call with kind: "origin" returns the origin PDF and permanently consumes it; every later download must use kind: "copy" and returns a PDF watermarked "העתק" (copy). Deliver the origin PDF straight to the end customer. Recommended: use kind: "auto", which serves the origin on the first ever print and copies forever after, so a repeat download button never errors; the X-Print-Variant response header says which variant you got.

Document types

CodeNameWhenNeeds linesNeeds paymentsVAT
305חשבונית מס (tax invoice)Billing, payment later-
320חשבונית מס/קבלה (invoice/receipt)Billing + payment together, the common case
330חשבונית מס זיכוי (credit note)Correcting 305/320, issued via the credit-note endpoint and not directly-
400קבלה (receipt)Payment received (no VAT invoice)--

Dealer type decides what's allowed: an עוסק פטור ("patur") may issue only receipts (400), no VAT documents. "murshe" (עוסק מורשה), "company" (חברה) and "ngo" (עמותה) may issue all four. Sending a disallowed type returns doc_type_not_allowed. Ask your users their dealer type at onboarding and reflect this in your UI.