Create a sales invoice
Creates a sales invoice conforming to UBL 2.1 with PINT AE customization. See the right panel for request samples and response JSON.
Rate limit
60 requests/minute per authenticated account. See Rate limiting for response headers (X-RateLimit-*) and retry guidance.
Path parameters
Request body
Send the full sales invoice JSON in the request body. See the right panel for a complete request example.
Request fields
Fields in the request JSON. Rows are ordered Required → Conditional → Optional.
Required fields — always send on create.
Conditionally required fields — required only in some cases; see Validation and Conditional field rules below.
Optional fields — skip unless you need them.
Object fields (for example accounting_customer_party or document_lines) are documented in their own sections further down this page.
Do not send: accounting_supplier_party — the API sets the supplier from {profileId}. Do not send calculated or system fields (id, org_id, document_sequence, totals, meta_info, etc.) — those appear in the response only.
Conditional field rules
Customer party object
The accounting_customer_party field on create and resubmit requests. The supplier (accounting_supplier_party) is set automatically from the {profileId} business profile—do not send it.
Field requirements depend on customer type and address. See The Customer party object section for details.
Response party fields
Address object
Postal and delivery addresses use the shared address object structure.
Tax category object
Tax categories share the same structure on line items (classified_tax_category) and charge/allowance tax_category fields. classified_tax_category is required on each line. Document-level charge and allowance tax categories are required; line-level charge and allowance tax categories are optional.
Buyer customer party object
The buyer_customer_party field carries the Beneficiary ID (UBL BTAE-01). It is not a full party reference—only the beneficiary identifier is sent in the API.
Seller supplier party object
The seller_supplier_party field carries the Principle ID (UBL BTAE-14). It is not a full party reference—only the Principle ID TRN is sent in the API.
Payee party object
The payee_party field is an object with the following attributes:
Tax representative party object
The tax_representative_party field is an object with the following attributes:
Delivery object
The delivery field is an object with the following attributes. JSON property names use snake_case as shown.
Delivery location object
The delivery_location object has the following attributes.
Order reference object
The order_reference field is an object with the following attributes:
Billing reference object
Each element of the billing_reference array is an object with the following attributes:
Despatch document reference object
The despatch_document_reference field is an object with the following attributes:
Receipt document reference object
The receipt_document_reference field is an object with the following attributes:
Statement document reference object
The statement_document_reference field is an object with the following attributes:
Originator document reference object
The originator_document_reference field is an object with the following attributes:
Contract document reference object
The contract_document_reference field is an object with the following attributes:
Project reference object
The project_reference field is an object with the following attributes:
Price object
The price object on each document_lines[] entry carries the item net price and price base quantity.
Document line object
Each element of the document_lines array represents one invoice line (UBL InvoiceLine). Nested item fields map to the UBL Item group. For Item Type, HSN, and SAC mappings from your ERP or Marmin UI, see Line item classification (UI to API).
Invoice period object
Used at document level (invoice_period) and on document lines (document_lines[].invoice_period). If you include this object, all sub-field conditions below apply.
Order line reference object
Despatch line reference object
Line document reference object
Buyer item identification object
The buyer_item_identification field is an object with the following attributes:
Seller item identification object
The seller_item_identification field is an object with the following attributes:
Standard item identification object
The standard_item_identification field is an object with the following attributes:
Additional item identification object
Use this array for Service Accounting Code (SAC) when the line Item Type is Services (S) or Both (B). In Marmin UI this is the Service Accounting Code field—not the Item Type dropdown.
Each element of the additional_item_identification array is an object with the following attributes:
Line item classification (UI to API)
The tables below map common ERP/UI labels on a document line to the API fields on document_lines[]. Use them when building create payloads from your source system.
#### Item type
#### Item classification identifier (HSN)
Applies when Item Type is Goods (`G`) or Both (`B`).
#### Service accounting code (SAC)
Applies when Item Type is Services (`S`) or Both (`B`).
#### Related fields
Commodity classification object
The commodity_classification object carries Item Type, HSN (for goods), and reverse-charge metadata. See Line item classification (UI to API) for UI mappings.
Origin country object
Additional item property object
Charge object
Each element of the charges array is an object with the following attributes:
Allowance object
Each element of the allowances array is an object with the following attributes:
Attachment object (request)
Use these fields when sending attachments on create or update requests.
Attachment object (response)
Each element of attachments in document JSON responses (create, retrieve, list) includes metadata only. File bytes are not returned; use the Download attachment endpoint with attachments[].id.
file_content is request-only and is never included in responses.
Payment means array
The payment_means field is an array; each element is an object with the following attributes:
Card account object
The card_account field is an object with the following attributes:
Payee financial account object
The payee_financial_account field is an object with the following attributes:
Payment mandate object
The payment_mandate field is an object with the following attributes:
Payment terms object
The payment_terms field is an object with the following attributes:
Tax exchange rate object
The tax_exchange_rate field is an object with the following attributes:
Response meta_info object
The meta_info field is an object with the following attributes:
Peppol status object
The meta_info.peppol_status field is an object with the following attributes:
Status values
Client processing guidance:
Treat
overall_statusas the primary state for workflow decisions.Use
participant_statusandfta_statusas stage-specific diagnostics for UI and support logs.If
overall_statusisPENDING, keep the invoice in a processing state and poll/re-fetch later.If
overall_statusisAPPROVED, mark the Peppol flow as successful and continue normal downstream actions.If
overall_statusisREJECTEDorVALIDATION_FAILED, stop submission-dependent actions and surface the failure to users.When
validation_resultsis not empty, display user-friendly error summaries fromtext, and retainflag,reasonCode,location, andtestfor troubleshooting.participant_statusorfta_statuscan benullin early/failed validation stages; do not treatnullalone as success or failure.
Invoice type codes (380 and 480)
Choose invoice_type_code based on whether the business profile identified by {profileId} is VAT registered.
Non-AED invoices
When document_currency_code is not AED, the following rules apply (enforced at API validation):
Example exchange rate block for a USD invoice:
"document_currency_code": "USD",
"tax_currency_code": "AED",
"tax_exchange_rate": {
"source_currency_code": "USD",
"target_currency_code": "AED",
"calculation_rate": 3.6725
}See Non-AED invoice example section for details.
Invoice out of scope (type code 480)
Use invoice_type_code 480 when the supplier business profile is not liable for VAT or the supply falls outside UAE VAT scope.
See Out of scope invoice section for details.
Tax point date (UAE VAT)
tax_point_date (UBL IBT-007) is the date when VAT liability arises per UAE VAT Law.
Profile execution ID
profile_execution_id is an 8-character binary flag string (each character 0 or 1) that encodes UAE special transaction types per PINT AE. Use 00000000 for a standard sale invoice with no special types.
Set the corresponding position to 1 when the supply matches that scenario; leave it 0 otherwise. Multiple flags may be 1 when more than one scenario applies.
Ready-to-use payloads for each scenario are under Sale invoice examples.
Free Trade Zone (FTZ) — position 1 (`1XXXXXXX`)
Supply of goods or services in a Free Trade Zone (FTZ).
When this flag is 1, set buyer_customer_party.id to a valid Beneficiary TIN. See Buyer customer party object section for details. Example: Free Trade Zone.
Deemed supply — position 2 (`X1XXXXXX`)
Supply of goods or services without consideration.
When this flag is 1, payment_means may be omitted. The buyer must be a UAE party (accounting_customer_party.postal_address.country_code = AE); non-UAE B2B buyers are rejected. For cross-border supplies, use Exports instead. Example: Deemed supply.
Profit Margin Scheme — position 3 (`XX1XXXXX`)
Supply of goods under the profit margin scheme.
No additional mandatory fields beyond standard validation. Example: Profit margin scheme.
Summary invoice — position 4 (`XXX1XXXX`)
Taxable person makes more than one supply to the same person in the same calendar month.
When this flag is 1, invoice_period is required (IBR-138-AE). Provide at least one of start_date or end_date (IBR-CO-19); description is optional. Example: Summary invoice.
Continuous Supply — position 5 (`XXXX1XXX`)
Supply of goods and/or services made on a recurrent basis.
No additional mandatory fields beyond standard validation. Example: Continuous supply.
Disclosed Agent Billing — position 6 (`XXXXX1XX`)
An agent who is a VAT registrant makes a supply on behalf of the principal.
When this flag is 1, set seller_supplier_party.id to a valid Principle ID TRN that differs from the seller VAT identifier on the business profile. Example: Disclosed agent billing.
Supply through e-commerce — position 7 (`XXXXXX1X`)
Supply of goods or services via e-commerce.
When this flag is 1, delivery with delivery_location.address is required. street_name, city_name, country_subentity, and country_code are mandatory. Example: E-commerce supply.
Exports — position 8 (`XXXXXXX1`)
Supply of goods or services outside the UAE.
When this flag is 1, delivery with delivery_location.address is required. street_name, city_name, country_subentity, and country_code are mandatory; country_code must not be AE. accounting_customer_party.party_tax_scheme is optional when the buyer is non-UAE. Example: Export transaction with delivery.
*Each position X is 0 or 1 depending on your scenario.*
Related examples
Implementation notes
Differences between documentation, API validation, and Peppol transmission rules:
See Implementation notes for the full cross-document gap list.
Attachments
attachments carries document-level supporting files for the invoice—not line-level files on document_lines. Send each file as Base64-encoded binary inside the JSON body (not multipart upload, not a separate upload URL). The API stores attachments on the document and emits them in UBL as cac:AdditionalDocumentReference → cac:Attachment → cbc:EmbeddedDocumentBinaryObject. On create, omit attachments or send [].
Attachment object
Each element of the attachments array is an object with the following attributes:
API scope
GET responses return attachments in the same shape as the request.
Allowed `file_type` values
Any other value is rejected with a validation error such as *File type must be one of the allowed values*. Use image/jpeg for .jpg files—not image/jpg.
Validation rules
Field-level errors typically use paths such as attachments[0].file_type, attachments[0].file_content, etc.
Payload size
On create for the four invoice and credit-note POST endpoints above, the entire HTTP request body must be ≤ 8 MB. That limit includes all JSON—header, parties, lines, tax, and Base64 attachments (Base64 adds roughly 33% overhead). Over the limit, the API returns 413 with a message like *Payload size should not exceed 8MB*.
Compress PDFs, limit the number and size of files, and budget payload space: the server may append another PDF after validation (see below).
Server behavior on create
After validation, the service appends a system-generated PDF to any client-supplied attachments:
The response attachments may therefore include your files plus the generated PDF. Do not rely on array order; identify files by file_name and file_type.
Client implementation guide
Read file bytes from disk or memory.
Base64-encode with the standard alphabet (no
data:...;base64,prefix).Set
file_typeto an exact MIME string from the allowlist above.Set
file_namewith an extension that matches the content.Build the full document JSON; measure serialized size if you are near 8 MB.
On success, parse
attachmentsfrom the response; expectinvoice.pdforcredit-note.pdfon invoice/credit-note create.For display or download, decode
file_contentfrom Base64 client-side—GET responses return embedded content in the same shape.
Errors and HTTP status
Best practices
Prefer PDF for supporting documents and keep files small.
Assume the invoice or credit-note PDF is always added on create—do not upload a duplicate unless you need it.
If integrations fail with 413, reduce attachment size or handle supporting documents outside this API—the API does not support chunked upload.
Store returned Base64 carefully; responses can be large.
Required data
Customer party objects — Complete
accounting_customer_partywith name, address, and tax scheme when requiredBusiness profile identifier — Supplier
business_profile_idin the path; must exist in your organizationLine items — At least one document line with name, quantity, unit code, price, and classified tax category
VAT information — Tax category and scheme per line and for charges/allowances as applicable
System behavior
VAT rules are applied according to UAE VAT law
The sales invoice is recorded
Invoice status and transmission events are tracked
Validation rules
Response
Status code: 201 Created
Returns the created sales invoice with all request fields echoed plus system-generated and calculated fields.
Response body fields
Document lines in response
Each line includes calculated fields: base_amount, net_amount, total_amount, tax_amount. The price object in the response contains price_amount (instead of base_amount in the request).
Charges and allowances
Document-level charges and allowances are applied after line item totals
Line-level charges and allowances are applied per line item
All charges and allowances require a
tax_categoryfor proper VAT calculation
See the right panel for complete response JSON.
