Short answer: In Risiti App, submitted means KRA acceptance has been recorded. Draft, pending, retrying and failed need further attention before you share a final tax receipt. Read the error and acceptance evidence together: a timeout does not prove rejection, and a validation error may need correction rather than another automatic retry. API integrations use the separate submission result described below.
Status Meaning and Next Action
| Risiti App status | Meaning | Next action |
|---|---|---|
| Draft | A working record that is not a final accepted receipt | Review the details and any earlier submission history before submitting |
| Pending | Submission or confirmation remains unresolved | Keep the original record and establish the outcome |
| Retrying | Recovery is scheduled or in progress after a temporary failure | Monitor the same invoice and its next action |
| Failed | The request needs correction, investigation or supported recovery | Read the message and check acceptance evidence before retrying |
| Submitted | KRA acceptance has been recorded | Check receipt details, download the accepted PDF and share it |
API Integrations: Check the Canonical Submission Result
For Direct API or Platform API, inspect data.submission: successful completion requires submission.terminal and submission.succeeded to both be true. Legacy status or etims_status values of submitted do not prove acceptance. Keep the API invoice ID and follow its submission lifecycle.
Sandbox success remains simulated. A successful test result is not a KRA-signed production receipt or proof of live tax acceptance.
What Risiti App Retries Automatically
Risiti App separates temporary service or connection failures from errors requiring action. Its recovery queue selects eligible temporary failures; a field-validation rejection is excluded from that automatic queue until the underlying issue is addressed through the supported workflow.
A scheduled retry does not promise immediate acceptance. Keep the error, original reference and timestamps available if the invoice remains unresolved. Do not rebuild the sale just to get a different status label.
| Situation | What needs to happen |
|---|---|
| Temporary service failure | Controlled recovery of the original invoice |
| Invalid buyer, item or totals | Review and correct the identified data |
| Unknown outcome after a timeout | Reconcile whether the original request was accepted |
| Existing number without receipt proof | Investigate the existing fiscal record before another issuance |
Why an Existing Invoice Number Needs Investigation
An existing-number response can mean a prior request reached KRA, or it can identify a different conflict. It does not by itself prove that this sale has an accepted receipt.
Risiti App can recover returned receipt metadata or perform a supported reference repair in defined cases. Where a duplicate response lacks the necessary receipt proof, it stops for investigation. Do not assume every collision causes a safe automatic renumbering.
Accepted Invoice, Missing PDF
If KRA accepted the original sale but the PDF is unavailable, recover its receipt details and resolve PDF generation or download. Resubmitting the sale is not a PDF repair.
Before sharing the recovered document, match the seller, buyer where applicable, date, invoice identity and totals. A payment notification is separate evidence and cannot confirm KRA acceptance.
When the Accepted Invoice Itself Is Wrong
Preserve the original accepted transaction. Use the issuing solution's supported correction or credit-note flow, and retain the linked original, credit and replacement where required.
Changing a local status or editing the downloaded PDF does not change KRA's fiscal record.
Close the Day with an Exception List
- ✓List unresolved pending, retrying and failed invoices against the day's actual sales.
- ✓Record the original reference, error, last attempt and evidence of acceptance or uncertainty.
- ✓Assign one owner and next action: wait for scheduled recovery, correct data, recover a receipt or contact support.
- ✓Reconcile payments separately, including unpaid sales and refunds.
Official sources
Official guidance and legislation used to prepare this guide.
Frequently asked questions
Open a question to read the answer.
Does pending mean KRA rejected my invoice?
No. It means confirmation is unresolved. Keep the original record and check its outcome rather than creating another sale.
Will Risiti App automatically retry every failed invoice?
No. Temporary failures can enter controlled recovery; validation and other action-required failures need correction or investigation.
Does submitted always mean accepted?
It means acceptance has been recorded in Risiti App. For the Risiti API, inspect the canonical data.submission result; legacy submitted labels do not prove acceptance. Other providers' labels also need checking.
Should I submit again when the PDF is missing?
If the original invoice was accepted, recover its receipt data and PDF. Do not resubmit the sale merely to recreate a file.
Updated: 14 Sept 2026. Source-check scope and limitations, where recorded, appear below. This guide is not tax or legal advice. Confirm unusual cases with KRA or a qualified tax professional.
Keep reading
Selected from the same guide librarySource check: . Risiti's implemented retry classification, duplicate-receipt proof requirements and App/API status distinctions.
Product behaviour was checked against the code, not measured in a live incident. Other providers' status labels can mean something different.
What changed in this review
- Removed the implication that every rejection is automatically retried or safely renumbered.
- Added recovery and escalation choices without creating replacement sales.