On this page
If you are coming from a jurisdiction where debit notes and credit notes are both standard adjustment documents, the UAE PINT-AE specification has a real, easy-to-miss difference: it defines only two document types, Invoice and Credit Note. There is no Debit Note document type in UAE PINT-AE. This is not a gap in tooling or a feature that has not shipped yet. It is how the specification itself is scoped, and it changes how you should be modeling invoice adjustments from the start rather than something to work around later.
What UAE PINT-AE actually defines
PINT-AE is the UAE-specific implementation of the international Peppol invoice standard. Independent verification against the official specification confirms it defines two document types: Invoice, for the original transaction, and Credit Note, for reducing or reversing a previously issued invoice. A downward adjustment to an invoice, whether that is a partial refund, a pricing correction, or a full reversal, is modeled as a Credit Note against the original invoice.
If your source system represents adjustments internally as debit notes, that representation does not map onto a UAE PINT-AE document type. The adjustment itself is real and needs to be captured; the document type it needs to become, for FTA clearance purposes, is a Credit Note.
The credit note lifecycle
A credit note in Kodowo moves through a real, visible lifecycle, mirroring the same rigor invoices go through:
- Draft. The note has been created and references the originating invoice, but has not been submitted.
- Pending. The note has been submitted and is awaiting transmission through your accredited ASP.
- Submitted. The note has been transmitted.
- Accepted or Rejected. The terminal state, once your accredited ASP and the FTA have processed it.
A note in Draft or Pending status is cancellable. Once it has moved to Submitted, it follows the same accept-or-reject resolution path as an invoice, and every transition is recorded in the same append-only audit trail that covers invoices.
What a credit note submission actually looks like
Every credit note is created against a specific originating invoice, referenced by the ledger ID your system received when that invoice was originally submitted. That is a deliberate design choice: it means a credit note can never exist without a real, resolvable link back to the invoice it is adjusting.
curl -X POST https://api.kodowo.com/api/v1/compliance/notes \
-H "X-API-Key: $KODOWO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"note_type": "CREDIT",
"originating_ledger_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"source_reference": "CN-2026-00142",
"idempotency_key": "cn-2026-00142-v1",
"raw_payload": {
"reason": "Partial refund on returned goods",
"amount": 1250.00,
"currency": "AED"
}
}'
note_type only ever accepts "CREDIT". A "DEBIT" value is rejected with a validation error before it reaches anything else, which is the API surfacing the same constraint the specification itself imposes, rather than silently accepting a document type that could never actually clear the FTA.
Why "Debit" still exists at the database layer
If you inspect the underlying data model closely, you may notice the note type field is not narrowed to only allow "CREDIT" at the database layer, only at the API and application layer. That is intentional, not an inconsistency: it reserves room for a possible future where Kodowo supports additional jurisdictions whose specifications do define a Debit Note type, without requiring a schema migration to add it later. It is not a signal that debit notes are coming to UAE PINT-AE. They are not part of the specification, and nothing about this reservation changes that.
In the meantime, the application layer refuses to create a debit note under any circumstances, and the dashboard's credit note creation form only ever offers Credit Note as an option. There is no path, accidental or otherwise, to submitting a document type the UAE mandate does not recognize.
What to do with your existing debit note data
If your source system already generates debit notes internally for its own bookkeeping, you do not need to stop doing that. What needs to change is the mapping at the point invoice data reaches Kodowo: an internal debit note that represents a real reduction to an invoice needs to arrive as a Credit Note submission referencing that invoice, not as an attempted debit note. That mapping decision belongs in your integration layer, and getting it right before your Wave 1 or Wave 2 ASP appointment deadline is far cheaper than discovering the mismatch after invoices are already flowing.
