> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hitaji360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sales Invoices

> A sales invoice is the document you send a customer to ask for payment for goods or services you have delivered.

A sales invoice is the document you send a customer to ask for payment for goods or services you have delivered. In Hitaji 360 the invoice is also the source document that posts revenue and an account-receivable balance to your general ledger, so getting it right keeps both your customer relationship and your books in order.

This page walks through creating, editing, submitting, sending, and collecting on a sales invoice, the statuses an invoice moves through, and what happens behind the scenes in your accounts.

**You'll find this at:** `/accounting/invoices`

> 📷 *Screenshot: Sales Invoices list page with the status filter tabs and the "New Invoice" button — to be added.*

***

## Before you start

* **Which book am I in?** Invoices belong to an **accounting book** (the workspace selector at the top of the accounting area). If your organisation runs more than one business or set of books, confirm you are in the right one before creating an invoice — an invoice created in the wrong book posts to the wrong ledger and customer balance.
* **You need a customer contact.** An invoice must be addressed to a contact whose type is **Customer**. You cannot raise an invoice against a contact marked as a Vendor — the system will reject it. Create or convert the contact first under **Contacts**.

***

## The invoice lifecycle (statuses)

Every invoice carries a **status** (its workflow state). Knowing the status tells you what you can and cannot do with the document.

| Status               | Meaning                                                                     | What you can do                                          |
| -------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------- |
| **Draft**            | Just created; nothing has hit the ledger.                                   | Edit freely, delete, submit.                             |
| **Pending Approval** | Submitted and waiting for an approver (only when an approval rule applies). | Wait for approval/rejection.                             |
| **Approved**         | Cleared for issue; still not posted.                                        | Send to the customer.                                    |
| **Sent**             | Issued to the customer — the journal entry is now **posted**.               | Record payments, void (if unpaid), create a credit note. |
| **Partially Paid**   | One or more payments received, balance still outstanding.                   | Record more payments, create a credit note.              |
| **Paid**             | Fully settled — balance due is zero.                                        | Create a credit note (sales return).                     |
| **Overdue**          | Sent/partially paid and past its due date.                                  | Record payment, follow up, create a credit note.         |
| **Void**             | Cancelled — the journal entry has been reversed.                            | Nothing further.                                         |

Two important moments:

* **The ledger is only touched when the invoice is *sent*.** A Draft or Approved invoice has no effect on your accounts.
* **Once submitted, an invoice is locked.** A submitted/sent invoice cannot be edited in place. If you need to change a posted invoice you must either **void** it (if it has no payments) or **amend** it (which produces a fresh draft under a new invoice number and supersedes the original).

***

## Creating a sales invoice

From the Sales Invoices list, choose **New Invoice**.

> 📷 *Screenshot: New invoice form showing customer, dates, and the line-item editor — to be added.*

### Header fields

| Field                  | Required | Notes                                                                                      |
| ---------------------- | -------- | ------------------------------------------------------------------------------------------ |
| **Customer (contact)** | Yes      | Must be a Customer-type contact.                                                           |
| **Invoice number**     | No       | Auto-generated from your numbering series if you leave it blank.                           |
| **Issue date**         | Yes      | The date the invoice is dated and posted.                                                  |
| **Due date**           | Yes      | When payment is expected. **Cannot be earlier than the issue date** — the form rejects it. |
| **Notes**              | No       | Free text shown on the document (up to 1,000 characters).                                  |
| **Terms**              | No       | Payment terms / conditions printed on the invoice (up to 2,000 characters).                |
| **Default warehouse**  | No       | For stock-item lines; used when a line does not name its own warehouse.                    |

### Line items

Each line represents one thing you are charging for:

| Line field                       | Required | Notes                                                                                                                 |
| -------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------- |
| **Description**                  | Yes      | What is being charged for (up to 500 characters).                                                                     |
| **Quantity**                     | Yes      | Must be at least 0.01.                                                                                                |
| **Unit price**                   | Yes      | Price per unit; cannot be negative.                                                                                   |
| **Income account**               | No       | The revenue account this line credits. If left blank, the system uses your default **Sales** account at posting time. |
| **Tax rate (%)**                 | No       | E.g. enter `18` for 18% VAT on that line.                                                                             |
| **Stock item / Warehouse / UOM** | No       | Link the line to a stock item so issuing the invoice also writes a stock movement.                                    |

#### How totals are calculated

For each line, **line total = quantity × unit price**, and the line tax is **line total × (tax rate ÷ 100)**.

The invoice then rolls these up:

* **Subtotal** = sum of all line totals (before tax)
* **Tax amount** = sum of all line taxes
* **Total** = subtotal + tax amount

The new invoice is saved as a **Draft** with its **balance due** set equal to the total.

> **Discounts:** Sales invoices apply tax per line on the full line total; there is no document-level discount field on the sales invoice itself. If you need to offer discounts up front, build them into the line unit price or raise a **Quotation** first (quotations support both line-level and document-level discounts) and convert it to an invoice. To reduce an *already-issued* invoice, raise a **credit note** (see Related).

***

## Editing a draft

A **Draft** invoice can be edited freely — change the customer, dates, notes, terms, or rewrite the lines, and the totals recalculate.

Once an invoice has been **submitted, sent, partially paid, paid, or voided it can no longer be edited.** The system blocks the change and asks you to amend instead. This protects the integrity of anything already posted to the ledger.

***

## Submitting and approval

Choose **Submit** on a Draft invoice to move it forward.

* **If your book has an approval rule that matches this invoice** (for example, a value threshold), the invoice moves to **Pending Approval** and waits for an approver. It is locked while it waits.
* **If no approval rule applies**, the invoice is **auto-approved** immediately and jumps to **Approved**, ready to send.

This means most organisations without approval rules configured will see Submit take the invoice straight to Approved.

***

## Sending the invoice (this posts to the ledger)

Choose **Send to customer** on an Approved invoice. Sending does three things:

1. **Posts the journal entry** to your general ledger (see *Behind the scenes* below). This is the moment revenue and the receivable are recognised.
2. **Marks the invoice Sent** and stamps the send time.
3. **Emails the invoice PDF** to the customer's email address. If the contact has no email on file, the invoice is still marked Sent — only the email is skipped, and you'll see a note to that effect.

You can **resend** an invoice that is already Sent, Partially Paid, or Overdue to email the PDF again; resending does not post anything new.

> **EFRIS (URA fiscalisation):** If your business is configured for EFRIS e-invoicing, sending a sales invoice also fiscalises it with URA and stamps the legal fiscal document number (FDN), verification code, and QR onto the document. Depending on your transport mode this happens either before the ledger posts (online) or just after (offline). See the EFRIS page under Related for the full behaviour and what to do if fiscalisation fails.

> **Advances:** If you tagged customer advance payments onto the invoice, sending it automatically applies those advances against the new balance.

***

## Credit limits

Hitaji 360 has a credit-limit guard that can stop an invoice that would push a customer past an agreed limit, with a manager-override option on the create form (`Bypass the credit-limit guard`).

> ⚠️ **Current state:** This guard is part of an ongoing CRM rebuild and is **temporarily disconnected** in the running system, so invoices are not being blocked on credit limit today. Treat credit-limit control as a manual check until the rebuild reconnects it. (Flagged for the team — see Gaps.)

***

## Recording a payment against an invoice

When a customer pays, open the invoice and choose **Record payment**.

> 📷 *Screenshot: Invoice detail page with the "Record payment" action and the payment modal — to be added.*

* Recording a payment requires the **`accounting-payments:create`** permission.
* A payment can settle the invoice fully (→ **Paid**) or in part (→ **Partially Paid**); the invoice's **amount paid** and **balance due** update accordingly.
* You can view every payment applied to an invoice in its **Payments** history.

For the full payment workflow — deposit accounts, deductions/withholding, allocating one payment across several invoices — see the Payments page under Related.

***

## Overdue invoices and follow-ups

Each night the system automatically marks any **Sent** or **Partially Paid** invoice whose **due date** has passed as **Overdue**, so your receivables ageing stays current without manual effort.

For overdue invoices you can:

* **Mark as followed up** — record that finance chased the customer (stamps the follow-up time).
* **Snooze the follow-up** — push the invoice out of the overdue chase digest until a chosen future date.

These tools feed the Aged Receivables digest so your team chases the right invoices. The overdue reminder digest itself is covered on the Payments / receivables pages.

***

## Voiding an invoice

Voiding cancels a **posted** invoice and **reverses its journal entry**, backing out the revenue and receivable.

You can void an invoice only when:

* It has been **submitted** (a Draft can't be voided — **delete** it instead), and
* It has **no payments** recorded against it. If payments exist, refund/unapply them first.

A confirmation warns you that voiding reverses the journal entry and cannot be undone. If the invoice carried an EFRIS fiscal stamp, voiding also submits an EFRIS credit note to URA.

***

## Deleting a draft

A **Draft** invoice (no payments, nothing posted) can be **deleted** outright. The system refuses to delete any invoice that has payments — void it instead.

***

## Permissions

Actions on invoices are gated by these permission slugs (your role may have some and not others):

| Action                                        | Permission                   |
| --------------------------------------------- | ---------------------------- |
| View invoices                                 | `accounting-invoices:read`   |
| Create / raise a credit note                  | `accounting-invoices:create` |
| Edit, submit, amend, mark-followed-up, snooze | `accounting-invoices:update` |
| Delete a draft                                | `accounting-invoices:delete` |
| Send to customer                              | `accounting-invoices:send`   |
| Void                                          | `accounting-invoices:void`   |
| Submit through the formal document lifecycle  | `accounting-invoices:post`   |
| Record a payment                              | `accounting-payments:create` |

***

## Behind the scenes — the accounting

When an invoice is **sent**, Hitaji 360 posts a balanced journal entry. In plain double-entry terms:

|                                                 | Debit         | Credit                    |
| ----------------------------------------------- | ------------- | ------------------------- |
| **Accounts Receivable** (the customer owes you) | Invoice total |                           |
| **Sales / income account** (per line)           |               | Line amounts (net of tax) |
| **Tax Payable** (VAT you owe URA), if any       |               | Tax amount                |

So the customer's receivable balance goes up by the full invoice total, revenue is recognised on the income account(s), and any VAT charged is parked in a tax-payable account until you remit it. The receivable line is tagged to the customer so it shows correctly on their statement and in Aged Receivables.

When a **payment** is recorded, a second entry debits your bank/cash account and credits Accounts Receivable, reducing what the customer owes.

When an invoice is **voided**, the original journal entry is reversed — every debit and credit above is posted in the opposite direction, returning revenue, receivable, and tax to where they were.

> If sending fails with a message about a missing **Accounts Receivable**, **Sales**, or **Tax Payable** system account, your chart of accounts is missing one of these system accounts. Configure them in your chart of accounts (or contact support) and try again.

***

## Related

* [Quotations](/accounting/user/transactions/quotations) — quote a customer and convert it into an invoice
* [Credit notes & sales returns](/accounting/user/transactions/credit-notes) — reduce or reverse an issued invoice
* [Payments](/accounting/user/transactions/payments) — record, allocate, and reconcile customer payments
* [Contacts](/accounting/user/master-data/contacts) — create and manage customer contacts
* [EFRIS e-invoicing](/accounting/user/compliance/efris) — URA fiscalisation of sales invoices