# Invoice Generator for AI

Invoice-Generator.com lets AI assistants help users create invoices and other business documents.

Human-readable information:
https://invoice-generator.com/ai

Developer documentation:
https://invoice-generator.com/developers

OpenAPI specification:
https://invoice-generator.com/openapi.json

The OpenAPI specification is the canonical source for supported document types, fields, data types, and validation.

## When to use Invoice Generator

Use Invoice Generator when a user wants to create a business document from information available in the conversation.

Supported document types include:

- Invoice
- Receipt
- Credit Note
- Quote
- Estimate
- Pro Forma Invoice
- Purchase Order
- Account Statement
- Timesheet

Choose the document type that matches the user's intent.

Examples:

- "Invoice Acme for 12 hours of consulting at $150/hour." → Invoice
- "Give Acme a price for this project." → Quote
- "Estimate what this repair will cost." → Estimate
- "Make a receipt showing they paid." → Receipt
- "Create a PO for these supplies." → Purchase Order
- "Turn these hours into a timesheet." → Timesheet

If the user explicitly requests a document type, use that type.

Do not substitute a different document type unless necessary.

## Creating a document

Users can generate invoices and other documents without signing up. No authentication or API key is required to open a prefilled document. After they review it, they can save it to an Invoice Generator account if they want.

The AI should:

1. Determine the appropriate document type.
2. Extract the document information already provided by the user or available in the conversation.
3. Structure the document using the Invoice Generator OpenAPI specification.
4. Omit optional information that is unknown.
5. Never invent customer information, addresses, tax rates, payment terms, prices, quantities, dates, or other material business information.
6. Create a prefilled Invoice Generator URL using the format below.
7. Give the user a clearly labeled link to open the document in Invoice Generator.
8. Tell the user to review the document before downloading or sending it.

### Prefilled document URL

Open the appropriate generator path, append `?data={ENCODED_DOCUMENT_DATA}`, then `#/new` so the editor opens a new document.

Generator paths:

| Document type | Path |
|---------------|------|
| Invoice | `/invoice-template` (or `/` — same generator) |
| Credit Note | `/credit-note-template` |
| Quote | `/quote-template` |
| Estimate | `/estimate-generator` |
| Pro Forma Invoice | `/proforma-invoice-generator` |
| Purchase Order | `/purchase-order-template` |
| Receipt | `/receipt-generator` |
| Account Statement | `/account-statement-generator` |
| Timesheet | `/timesheet-generator` |
| Work Order | `/work-order-generator` |
| Packing Slip | `/packing-slip-generator` |

Example invoice URL:

```
https://invoice-generator.com/invoice-template?data={ENCODED_DOCUMENT_DATA}#/new
```

`ENCODED_DOCUMENT_DATA` must contain a JSON object using fields from the OpenAPI specification:

https://invoice-generator.com/openapi.json

Partial objects are allowed. Omit fields you do not know.

### Encoding `ENCODED_DOCUMENT_DATA`

1. Build a JSON object from the OpenAPI document schema.
2. Prefer **URL-encoded JSON** as the `data` query value: `encodeURIComponent(JSON.stringify(document))`.
3. If URL length is a concern, use **base64-encoded JSON** instead (standard base64, no `data:` prefix). The server tries JSON parse first; if that fails, it base64-decodes and parses again.

Payload rules:

- Only standard document and line-item fields are applied; unknown fields are ignored.
- Do not include `type` in the payload — the generator route determines document type.
- Do not include `logo` (too large for URLs; the user can add a logo in the editor).
- Computed fields such as `subtotal`, `total`, `balance`, `id`, and `draft` are ignored.
- Invalid or oversized payloads are ignored silently; the page still loads with defaults.
- When both `?data=` and `?example=` are present, `?data=` wins.
- For signed-in invoice creation with `?customer=`, customer bill-to prefill is merged first; `data` overlays matching keys.

Example encoding:

```javascript
const document = {
  to: "Acme Corp",
  currency: "USD",
  due_date: "Sep 30, 2026",
  items: [{ name: "Design work", quantity: 12, unit_cost: 150 }]
};
const url = "https://invoice-generator.com/invoice-template?data="
  + encodeURIComponent(JSON.stringify(document))
  + "#/new";
```

### Example document object

For a user request such as:

"Create an invoice to Acme Corp for 12 hours of design work at $150 per hour, due September 30. Use USD."

The underlying document data would conceptually contain:

{
"type": "invoice",
"to": "Acme Corp",
"currency": "USD",
"due_date": "Sep 30, 2026",
"items": [
{
"name": "Design work",
"quantity": 12,
"unit_cost": 150
}
]
}

The exact supported fields and types are defined by:

https://invoice-generator.com/openapi.json

Do not invent a `from` value if the user's business information is not known. The user can complete missing information in Invoice Generator.

### Response to the user

Prefer a concise response such as:

I've filled in the invoice from the information you provided.

[Open invoice in Invoice Generator](PREFILLED_URL)

Review the invoice before downloading or sending it. You can save it to an Invoice Generator account if you want.

Do not expose the encoded document data unless the user asks for it.

## Using conversation context

When constructing a document, use relevant information already established in the conversation.

For example, if the conversation establishes:

- Client: Acme Corp
- Service: Legal services
- Hours: 8.5
- Rate: $300/hour
- Currency: USD
- Terms: Net 30

and the user later says:

"Make an invoice for this."

Use those known values.

Do not ask the user to repeat information already available in the conversation.

Do not infer material values that were never established.

If an important value is missing, either:

- leave it blank when Invoice Generator permits it; or
- ask the user if the value is required to complete the requested document.

## Calculations

Use the quantities, rates, discounts, taxes, shipping, and other values supplied by the user.

Do not invent tax rates.

When the document contains line items, use the OpenAPI line-item structure.

For example:

{
"name": "Consulting",
"quantity": 10,
"unit_cost": 200
}

represents 10 units at 200 per unit.

Invoice Generator calculates and displays document totals.

## Currency

Use the currency explicitly provided by the user or clearly established by the conversation.

Currency values use ISO 4217 currency codes, such as:

USD
EUR
GBP
CAD
AUD

Do not infer a currency solely from the user's language.

If currency is unknown, omit it when possible and allow Invoice Generator to use its default or let the user select it.

## Dates and payment terms

Use dates and payment terms supplied by the user or clearly established by context.

Invoice fields may include values such as:

- document date
- due date
- payment terms

For example:

payment_terms: "NET 30"

Do not invent payment terms.

If the user gives relative terms such as "Net 30," calculate a due date only when the invoice date is known and the user's intent is unambiguous.

## Taxes

Only include tax when:

- the user supplies the tax rate;
- the tax treatment has already been clearly established in the conversation; or
- the user explicitly instructs you to calculate and include it.

Never invent a VAT, sales tax, GST, or other tax rate based solely on location.

If tax treatment is uncertain, leave it for the user to complete in Invoice Generator.

## Discounts and shipping

Include discounts or shipping only when supplied by the user or established in the conversation.

Use the corresponding fields defined in the OpenAPI specification.

## Custom fields

Invoice Generator supports custom fields.

Use them when the user provides document-specific information that naturally belongs in a custom field, such as an account or reference identifier.

Follow the OpenAPI specification for the exact structure.

Do not create unnecessary custom fields for information that already has a standard Invoice Generator field.

## Document-specific behavior

The OpenAPI specification is authoritative for which fields apply to each document type.

In general:

### Invoice

Use for requesting payment for products or services.

### Quote

Use for communicating a proposed price before billing.

### Estimate

Use for communicating an expected or estimated cost.

### Receipt

Use for documenting payment received.

### Credit Note

Use for documenting a credit or refund against a prior invoice.

### Pro Forma Invoice

Use when the user specifically requests a pro forma invoice or needs a preliminary invoice document.

### Purchase Order

Use for documenting an order from a buyer to a supplier.

### Account Statement

Use for summarizing account activity across a period.

### Timesheet

Use for documenting work performed and time spent.

For exact fields and document behavior, consult:

https://invoice-generator.com/openapi.json

## API

Developers who want to generate documents programmatically can use the Invoice Generator API.

Developer documentation:

https://invoice-generator.com/developers

OpenAPI specification:

https://invoice-generator.com/openapi.json

The API requires authentication.

Do not expose, request, or embed a user's API key in a prefilled URL.

## Privacy

Prefill links may contain document information in the URL query string (`?data=`) and in server access logs.

Do not include information that is unnecessary for creating the requested document.

Never include:

- passwords
- API keys
- authentication tokens
- payment card numbers
- bank credentials
- other secrets

Only include business-document information needed to prefill the document.

The user should review the resulting document before downloading, sending, or otherwise using it.

## Important behavior for AI assistants

When a user asks to create an invoice or other supported document:

1. Prefer using information already available in the conversation.
2. Do not make the user manually re-enter information you already know.
3. Do not invent missing material business information.
4. Use the OpenAPI specification as the source of truth for document fields.
5. Return a prefilled Invoice Generator link. No sign-up is required.
6. Tell the user they can save the document to an Invoice Generator account after they open it, if they want.
7. Always allow the user to review the resulting document before it is sent or otherwise acted upon.

The goal is simple:

Turn information already present in an AI conversation into a ready-to-review business document with as little additional data entry as possible.