Automated invoice creation

How automated invoice creation works

The pipeline has four stages:

1. Intake. A supplier emails an invoice to your account's ingestion address. Navigator captures the email and any PDF or image attachments.
2. Extraction. Navigator uses AI vision to read each attachment and pull out structured invoice data — supplier, customer, reference, dates, line items, totals, bank details.
3. Validation. The extracted data is checked against 40+ rules covering the supplier, customer, budgets, dates, support item codes, pricing, duplicates, and more.
4. Decision. Based on the outcome, Navigator either auto-creates the invoice, flags it for human review, or rejects it and emails the supplier asking them to fix it.

Every inbound invoice goes through the same pipeline. The outcome determines what happens next.

How an invoice enters the pipeline

Every account has a unique email address suppliers can use to submit invoices. When an email arrives:

• Navigator parses the email and stores it against your account
• If the email has attachments, a task is created for the invoice
• The task is picked up by the automation pipeline

Emails without attachments aren't treated as invoices — they're handled through the normal inbox workflow.

What Navigator extracts from the document

Navigator uses AI vision — a large language model that can read documents and images — to pull out a structured set of fields from the invoice:

• Supplier details — business name, ABN, BSB, account number and name, email, address
• Customer details — participant name, NDIS number, address
• Invoice metadata — reference number, issue date, due date, invoice total
• Line items — for each line, the NDIS support item code, description, service period start and end, quantity, and unit price

Extraction is good but not infallible — handwriting, unusual layouts, or poor scans can cause fields to be missed or misread. The validation stage catches most of these and either flags the invoice for review or sends it back to the supplier.

Validation checks

Navigator runs every extracted invoice through a series of checks. Each check has an outcome of failed (reject and email the supplier) or review required (flag for your team to action manually). Checks are grouped by what they look at.

Supplier checks

• ABN exists and is 11 digits — if missing or malformed, the invoice can't be processed
• ABN matches the supplier on record — the ABN on the invoice must match what's saved against the supplier in Navigator
• ABN is active — checked against the Australian Business Register. Cancelled ABNs block automation
• ABN is not on an enforcement ban list — NDIS-banned providers are blocked
• Only one supplier record per ABN — if two supplier records share an ABN, Navigator can't tell which one to use
• Bank details present and valid — BSB and account number must be complete and correctly formatted. Missing bank details prevent payment extracts later on

Customer checks

• Customer has a date of birth — required for age-based validations (see ECEI below)
• Customer isn't flagged to skip automation — customers can be configured to never auto-create (for example, during onboarding or when extra oversight is required)

Budget and plan checks

• Active support plan covers the service dates — the invoice's service period must fall within a current plan
• Invoice doesn't span multiple plans — service dates must all sit within a single support plan (no crossing plan changes)
• Budget exists for each line item's category — if the plan has no matching budget, automation pauses
• Budget has enough funds remaining — if the invoice would push the budget negative, it's flagged for review
• Budget category matches the NDIS support item — line items can't be paid from the wrong budget category

Date checks

• Issue date not in the future
• Period start before period end
• Period end not in the future — you can't invoice for services that haven't happened yet
• Service dates within the support plan's date range

NDIS support item checks

• Item code is active on the service date — NDIS periodically retires codes. If the code wasn't active during the service period, it's flagged
• Unit price matches the NDIS price — unit prices are validated against NDIS price limits for the relevant service region
• Unit price doesn't exceed the NDIS limit — overcharges are blocked
• Hourly items use hourly unit pricing — if a code is priced per hour, the invoice must reflect that
• Day-of-week codes match the service date — Saturday, Sunday, and public holiday codes must align with the actual date
• Public holiday codes match real public holidays — claiming a public holiday rate on a Tuesday is blocked
• Activity-based transport and provider travel rules — these have their own specific structural checks

Duplicate checks

• Not a duplicate in Navigator — same supplier, customer, and invoice reference already exists
• Not a duplicate in the external system — PRODA or the relevant external claiming system already has this invoice reference

Amount checks

• Invoice total matches the sum of line items — arithmetic errors are blocked
• Invoice total below the automation threshold — invoices over $3,000 are always flagged for review, regardless of everything else

Special-case code checks

• GST code is valid — non-standard GST classifications are flagged
• Cancellation reason is valid if present — cancelled service codes must include a recognised reason

What gets auto-created

For Navigator to auto-create the invoice without human review, all of these have to be true:

• All validation checks pass
• The account has automated invoice creation enabled
• The customer doesn't have Auto-create disabled set
• The supplier doesn't have Auto-create disabled set
• Every line item uses a code from Navigator's safe code list — a curated subset of NDIS support item codes that have been reviewed and approved for automation

The safe code list exists because some NDIS codes (low-cost assistive tech, behaviour support plans, specialised disability accommodation, some community access items) have rules or audit implications that make full automation risky. Invoices containing those codes pass to review instead — your team approves them, Navigator learns the pattern, and over time more codes are added to the safe list.

What's blocked for review

When a check returns review required, the invoice is extracted and the task is left in the queue with status Review required. Your team opens it, sees what the automation flagged, and actions it manually — approving, amending, or rejecting as appropriate. Common review-required reasons:

• Supplier ABN is missing, malformed, or belongs to more than one supplier record
• Service date sits outside the support plan's date range
• Plan is missing a budget for the line item's category
• Budget doesn't have enough funds remaining
• Unit price has changed since the NDIS last published the price for that code
• Day-of-week code doesn't match the actual service date
• Duplicate detected in Navigator or the external system
• Invoice total exceeds $3,000
• Line items use codes outside the safe list

What's rejected outright

A small number of checks return failed instead of review required. Failed invoices are rejected and an email goes back to the supplier asking them to fix the issue and resubmit. Rejections happen for:

• ECEI codes for adult participants. Early Childhood Early Intervention codes are only valid for participants under a specific age. If a supplier bills an ECEI code for an adult, the invoice is rejected automatically.
• Adult-only codes for children. The inverse — some codes are restricted to adults and can't be claimed for a child.
• ABN mismatch with the supplier record. The invoice claims to be from a supplier, but the ABN doesn't match what Navigator has on file.
• ABN cancelled or banned. The supplier's ABN is inactive in the Australian Business Register, or on the NDIS enforcement list.
• Invoice total doesn't add up. The declared invoice total doesn't match the sum of the line items.
• Cancellation without a reason. The invoice claims a cancelled service but provides no cancellation reason code, or an invalid one.
• Invalid GST code.

These are cases where the supplier needs to correct something on their end before Navigator can process the invoice. See Automated invoice replies for the exact email that gets sent.

How to see and manage automated invoices

Every invoice task carries an automation status that tells you the outcome. The full list is in Invoice automation status. The day-to-day ones are:

• Passed — auto-created, no human action needed
• Review required — needs your team to action
• Failed — rejected, supplier has been notified

Filtering the task queue. In the Tasks area, filter by automation status to focus on what needs your attention. Most teams run through Review required daily. Failed is usually a light-touch check — the supplier has already been told, and you'll hear back from them if they disagree.

Seeing why something was flagged. Open the task. The automation errors are listed with the specific code and reason. If the error is correct, amend the invoice; if the automation was wrong, use Complete review to push it through.

Turning off automation for a customer or supplier. On the customer or supplier record, enable the Auto-create disabled flag. Invoices for that customer or supplier will still be extracted and checked — they just won't auto-create even if they pass. Useful during onboarding, disputes, or when extra oversight is needed.