Invoice Generator

You MUST ask clarifying questions before writing any code. Ask about:

1. Seller info — Business name, address, email, phone, logo (if any), VAT/tax ID (if applicable)
2. Client info — Client/company name, address, contact email, VAT number (if B2B in EU)
3. Line items — Description of each service/product, quantity, rate/price per unit
4. Payment terms — Net 30, due on receipt, etc. + preferred payment method (bank transfer, Stripe, PayPal, etc.)
5. Invoice number — Do they have an existing numbering scheme, or should you start one?
6. Dates — Invoice date, service/delivery date (if different), due date
7. Tax — What tax rate applies? (Sales tax, VAT, ITBIS, none?) This depends on jurisdiction.
8. Where is the seller based? — Determines required legal fields, page size (US = Letter, everyone else = A4), and tax handling
9. Billing contact email — Always ask explicitly. Do NOT invent a placeholder like [email protected] — the user must confirm the real email address.
10. Production domain — Always ask what domain the app is deployed to. Do NOT use the Replit dev domain or a made-up domain on the invoice itself.

How to ask

Start with the essentials:

"To create your invoice, I need a few details:

1. Your business name and address (the seller)
2. Who you're billing — client name and address
3. What you're billing for — list each item/service with the quantity and price
4. Payment terms — when is it due, and how should they pay?
5. What email should clients contact for billing questions?
6. What domain is your app deployed to (for the website shown on the invoice)?"

Then follow up for tax details, numbering, branding, etc. based on what they share.

If the invoice feels incomplete

If the user gives vague descriptions like "consulting work," push for specifics: "Can you break that down into specific deliverables? e.g., 'Website redesign — 3 revision rounds' at $5,000. Specific line items look more professional and reduce client pushback."

Flag Guesses and Inferred Details

If you had to guess or infer any details — tax rates, payment terms, invoice numbers, dates — you MUST tell the user what you assumed. After presenting the first draft, explicitly list anything you weren't sure about. For example:

"A few things I assumed — let me know if any need adjusting:

• I used invoice number INV-2026-0001 — do you have an existing numbering scheme?
• I set the tax rate to 0% since you didn't mention taxes — should I add sales tax or VAT?
• I set payment terms to Net 30 with a due date of April 13 — is that right?"

Do NOT silently present fabricated details as fact. Getting invoice details wrong can cause real payment and legal issues.

Two Approaches: Choose Based on Use Case

Approach A — Standalone HTML (preferred for SaaS/subscription templates)

Use when: The same invoice template will be sent to many different clients (e.g., a subscription SaaS billing its users). Client-specific data (name, email, invoice number, dates, amount) is passed via URL query parameters. One file serves all clients.

Architecture:

client/public/invoice-template.html   # Single file, URL-param driven

How it works:

• The template lives in the main app's public/ folder, served as a static asset
• All client-specific fields are read from URLSearchParams at runtime
• Seller info, domain, and billing email are hardcoded (they never change)
• Client pastes the parameterized link into any browser → prints to PDF

File location: client/public/invoice-template.html → served at /invoice-template.html

Approach B — React Component (preferred for one-off custom invoices)

Use when: Building a one-off invoice for a specific client with complex line items, custom branding per client, or when integrated into an app's billing flow.

Architecture:

artifacts/<client>-invoice/
  client/src/pages/Invoice.tsx   # Invoice data + component with auto-scale
  client/src/index.css           # Print-ready styles (A4 or Letter)

URL Parameter Pattern (Approach A)

This is the cleanest pattern for subscription/SaaS invoices. Every field that varies per client is a query param; everything that belongs to the seller is hardcoded.

Supported parameters

Example parameterized URL