Xero Invoice Status Authorised: What Approved Really Means

In the Xero API, AUTHORISED is the status of an invoice or bill that has been approved and is ready for payment but is not yet paid. The same underlying state shows up in the Xero UI under two different labels depending on what kind of document you are looking at: on a sales invoice, an AUTHORISED document is labelled Approved and, once a payment is due, appears in the Awaiting Payment list; on a bill, an AUTHORISED document appears directly in the Awaiting Payment tab on the Bills to Pay screen.

That one mapping resolves nearly every question about what Authorised means in Xero. The Xero invoice status AUTHORISED only ever appears in the API, in vendor integration settings, and in third-party docs that mirror the API vocabulary. The Xero UI itself never shows you the word Authorised on a sales invoice or a bill, which is what makes the term feel foreign the first time you see it.

In the lifecycle, AUTHORISED sits between SUBMITTED (the API state behind the UI label Awaiting Approval) and PAID. A document moves from DRAFT to SUBMITTED when it is sent for approval, from SUBMITTED to AUTHORISED when it is approved, and from AUTHORISED to PAID when a payment is reconciled against it.

AUTHORISED is also the strictest status to write to. Whether you are pushing data through the Xero API, through CSV import, or through a third-party integration, landing a document directly at AUTHORISED requires a complete and valid contact, line items with valid account codes, coherent tax treatment, and totals that reconcile. Incomplete data that would silently land as a DRAFT will hard-fail at the write call when you try to post it as AUTHORISED.

---

The Xero Invoice Status Lifecycle From Draft to Paid

Every invoice and bill in Xero moves through the same lifecycle: DRAFT → SUBMITTED → AUTHORISED → PAID. The API uses one set of names for each state; the UI uses another. Most of the confusion in working with Xero invoice status comes from the gap between the two.

API status	UI label (sales invoice)	UI label (bill)	What the state means
DRAFT	Draft	Draft	The document is editable and is not committed to the ledger. No required-field strictness.
SUBMITTED	Awaiting Approval	Awaiting Approval	The document has been submitted for approval and is waiting on a reviewer or an approval app. Used most heavily on bills.
AUTHORISED	Approved (then sits in Awaiting Payment)	Awaiting Payment	The document has been approved and is ready for payment.
PAID	Paid	Paid	A payment has been reconciled against the document.
VOIDED	Voided	Voided	The document has been cancelled but kept in the ledger for audit trail.
DELETED	Deleted	Deleted	The document has been removed entirely. Only reachable from DRAFT.

A few points are worth pulling out of the table.

SUBMITTED is where the API and UI names diverge first. The API name SUBMITTED is rendered as Awaiting Approval in the UI. This is the first place many bookkeepers lose the thread when they read a Xero developer doc or a third-party integration setting and try to match it to what they see on screen. The state exists on both sales invoices and bills, but in practice it is used far more heavily on the bills side, because internal approval is the dominant workflow there.

The state after Approved is Paid, not another approval step. Once a sales invoice is approved (AUTHORISED), the only forward transition is to PAID, which is triggered by reconciling a payment against the document. There is no further approval gate built into the lifecycle.

VOIDED and DELETED are terminal but different. DELETED is only reachable from DRAFT — once a document is AUTHORISED, you cannot delete it because it has accounting impact. To cancel an already-approved document, the correct path is VOIDED, which keeps the record in the ledger so the audit trail stays intact.

---

Sales Invoices: Approved Is Authorised in the UI

The button that moves a draft sales invoice into AUTHORISED is literally called Approve, which is most of the reason the API word feels disconnected from the UI you actually click through.

The full UI path on the sales side looks like this. A new sales invoice is created in Draft. If your team uses an internal approval step, the invoice can be sent for approval and shows in the Awaiting Approval view while it waits (this is the SUBMITTED API state, used less often on the sales side than on bills, but it does exist). Once the invoice is approved, the document carries the Approved label, and the same record then appears in the Awaiting Payment list view because it is approved and is now waiting for the customer to pay.

The same logic answers the Awaiting Payment question: there is no separate Awaiting Payment status on a sales invoice. Awaiting Payment is a list view, not a state. The list shows every sales invoice in AUTHORISED that has not yet been reconciled to a payment. The document-level label (Approved) and the list-level location (Awaiting Payment) are two different views of one underlying API state.

Once a sales invoice is in this state, it can be sent to the customer, payments can be allocated against it, and credit notes can be applied. It is the operational state where the document does real work in the AR ledger.

Bills: Awaiting Approval and Awaiting Payment in the UI

On a bill, the API status AUTHORISED shows up in the UI as the bill appearing in the Awaiting Payment tab on the Bills to Pay screen. The bills side has no separate "Approved" label step the way sales invoices do. A bill moves from Draft, optionally through Awaiting Approval (API status SUBMITTED), and into Awaiting Payment (API status AUTHORISED), and that is the whole pre-payment path.

A bill's AUTHORISED status, in practical terms, is the row you see in the Awaiting Payment tab. That tab is the list of every AUTHORISED bill that has not yet been paid; the tab name describes what is in the list, not a separate state.

The relationship between Awaiting Approval and AUTHORISED is sequential. Awaiting Approval is the UI label for SUBMITTED, the state immediately before AUTHORISED in the bill lifecycle. The transition between them is the act of approving the bill — either by a Xero user clicking through the in-product approval step, or by a third-party approval app signing off externally and pushing the status forward. Once that transition happens, the bill leaves the Awaiting Approval tab and lands in Awaiting Payment.

This is where third-party approval apps such as ApprovalMax fit in. They do not introduce a new Xero status. They sit on top of SUBMITTED, route the bill through their own internal approval workflow (multi-step approver chains, delegated approvers, conditional routing on amount or coding), and then push the bill to AUTHORISED once their workflow signs off. Native Xero approval, without a third-party app, does the same SUBMITTED → AUTHORISED transition by direct user action. Xero's native bill approval workflow is the in-product path; approval apps are a layer that replaces the human routing while leaving the Xero status flow underneath unchanged.

There is one operational consequence of reaching AUTHORISED that matters more than any of the others on the bills side: only AUTHORISED bills are selectable for batch payment and for payment-run scheduling. DRAFT and SUBMITTED bills are not visible to the batch payment workflow at all. If a bill needs to be paid in a scheduled run, it has to be AUTHORISED before the run is built, which is the operational reason the status choice matters at posting time — not just at audit time when someone later asks why an unreviewed bill ended up in the payment queue.

---

Choosing a Post Status for Extracted Invoice Data

The right post status for an integration is not a default to be set once and forgotten. It is a function of how reliable the upstream data is and how much reviewer capacity sits between that data and the ledger. The status decision is only safe when the upstream extraction is reliable. Anything pushed at AUTHORISED is in the payment queue immediately; anything pushed at DRAFT is parked for human eyes. Choose accordingly.

Treat the three options as a graded framework rather than a preference:

• DRAFT is the right choice when extraction confidence is low, field completeness is partial, supplier or account coding is uncertain, or no source document is attached to the record. Drafts park the data inside Xero without committing it. Every field stays editable by a reviewer, the document is not visible to payment runs, and nothing has accounting impact until someone signs off. This is the correct default when an integration is new, when source documents are mixed quality, or when supplier coding rules have not been hardened.
• SUBMITTED (Awaiting Approval) is the right choice when the data is clean enough that a reviewer can confirm rather than rebuild. Required fields are present, line items reconcile to the invoice total, tax treatment is coherent, and the source document is attached or directly traceable through a reference. This is the right level when there is a real reviewer in the loop but the workflow does not have controls strong enough to skip review — most production AP pipelines pushing extracted bills land here.
• AUTHORISED is only the right choice when the workflow has intentional controls: validated extraction confidence on every field, complete and reconciled data, source evidence attached to the document or directly traceable through a reference, supplier-coding rules that have been tested against real history, and a clear audit trail back to the original document. AUTHORISED is also the strictest write target — the post will hard-fail on incomplete fields that would have silently landed as DRAFT. Treat that strictness as a feature: if your data cannot pass it, posting at AUTHORISED was the wrong choice anyway.

Getting this wrong has operational cost, not just an audit footnote. Posting unreviewed extraction output as AUTHORISED adds avoidable noise to AP — duplicate bills that should have been caught at review, miscoded expenses that have to be journaled out later, mistaken supplier records that pollute payment runs. Atradius' 2025 B2B Payment Practices Barometer for North America found that 43% of B2B credit sales in the United States were overdue in 2025, with administrative inefficiencies in customer payment processes among the top reasons cited for late payment. Status-choice mistakes on the AP side are exactly that kind of administrative inefficiency, and the posting decision is where you control whether your team adds to that friction or removes it.

Clean upstream extraction is what makes that posture possible. We build AI-powered invoice data extraction for this part of the pipeline; every output row carries a reference to the source file and page, so the underlying document can be verified at the point of approval rather than trusted blind, which is what makes the data clean enough to defend a SUBMITTED or AUTHORISED post target rather than treat that target as a guess.

On the developer side, the implication is that validation belongs upstream of the post call. The integration should check completeness, tax coherence, total reconciliation, and supplier resolution before deciding what status to write, and downgrade the post status when any check fails rather than letting the Xero API reject the write at the boundary. Validating extracted invoice data before posting it through the API covers the validation step in more depth; the relevant point here is that the status choice is the natural output of that validation, not an input to it.

---

Required Fields, Import Defaults, and a Developer Note

Required fields shift sharply across the lifecycle. DRAFT is permissive: a sales invoice or a bill can be saved with a missing contact, missing line-item account coding, missing tax detail, or unresolved totals, and Xero will accept it as a parked record. SUBMITTED carries the same field requirements as AUTHORISED, because submitting a document for approval means submitting it as-is for sign-off — the approver should not have to add fields that the integration did not capture. AUTHORISED requires a valid contact, line items with valid account codes, coherent tax treatment, and consistent totals: line-item subtotals must agree with the invoice total. Pushing incomplete data as AUTHORISED through the API or through import will hard-fail at the write call; pushing the same data as DRAFT will silently land in the ledger as an editable draft, which is part of why integrations expose the status choice in the first place.

Import-tool defaults matter for the same reason. Native CSV import and the Conversion Toolbox typically default imported invoices and bills to DRAFT — these are one-shot bulk loads with no review queue behind them, and DRAFT is the safest landing point because the operator has to come back to the imported records anyway before anything is ready to pay. For the broader import path, see methods for converting PDF invoices into Xero.

Document-capture tools sit in a different shape. They feed an ongoing queue of incoming supplier documents rather than a one-shot batch, so they generally land output at the Draft or Awaiting Approval stage to slot into a continuous review workflow rather than direct to Awaiting Payment. Xero OCR and invoice scanning options covers how the Xero-side capture products handle that landing-status question.

For developers integrating against the Xero Accounting API, the status enum is the same on the Invoice and Bill (ACCREC and ACCPAY) endpoints: DRAFT, SUBMITTED, AUTHORISED, PAID, VOIDED, DELETED. The only meaningful difference between sales-invoice and bill behaviour is the UI label set rendered around the same underlying API state — Approved plus the Awaiting Payment list for sales invoices, the Awaiting Payment tab for bills. The API never speaks UI vocabulary; the UI never shows the API enum. Anywhere a third-party tool, integration setting, or developer doc mentions "Authorised," it is talking about the same AUTHORISED state regardless of whether the document is ACCREC or ACCPAY.