agentleFS
norman-financenorman-finance/norman-mcp-server/skills/create-invoice/SKILL.md

create-invoice

Skill65 starsChanged 11 days agoMITView on GitHub

Create and optionally send a new invoice to a client. Use when the user wants to invoice someone, bill a client, or create a new Rechnung or faktura.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 2 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Identify the client: If a client name is provided in $ARGUMENTS, call list_clients and find the matching client.

    line 18
  2. Very specific:

    Create the invoice: Call create_invoice with all gathered details.

    line 26
  3. Very specific:

    Send: Ask the user if they want to send the invoice now.

    line 30
  4. Distinctive:

    Use the company's default currency unless the user names another.

    line 33
  5. Distinctive:

    Default VAT rates: DE: 19% (7% for reduced rate items like food, books) / PL: 23% (8% or 5% reduced rates)

    line 34
  6. Very specific:

    Read get_invoice_settings for the company logo and saved defaults.

    line 39
  7. Very specific:

    If the user wants a different design, call list_invoice_templates.

    line 40
  8. Very specific:

    Use update_invoice_settings only when the user wants to change future document defaults.

    line 43

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Help the user create and send an invoice step by step:

  1. Identify the client: If a client name is provided in $ARGUMENTS, call list_clients and find the matching client. If ambiguous, ask the user to clarify. If no client exists, offer to create one with create_client.
  2. Gather invoice details: Collect the following information (ask for anything not provided):
    • Line items: description, quantity, unit price, VAT rate (DE: default 19% / PL: default 23%)
    • Invoice date (default: today)
    • Due date / payment terms (default: 14 days)
    • Any notes or special terms
  3. Create the invoice: Call create_invoice with all gathered details. Use the correct client_id from step 1.
  4. Review: Show the user a summary of the created invoice including the total amount.
  5. Send: Ask the user if they want to send the invoice now. If yes, call send_invoice to email it to the client. Omit subject and body to use the company's email template; pass additional_emails for CC recipients.

Important:

  • Use the company's default currency unless the user names another.
  • Default VAT rates: DE: 19% (7% for reduced rate items like food, books) / PL: 23% (8% or 5% reduced rates)
  • Invoice numbers are auto-generated by Norman
  • For recurring work, suggest create_recurring_invoice instead

Invoice appearance and edits:

  • Read get_invoice_settings for the company logo and saved defaults. Pass the saved language/currency when the user does not choose others.
  • If the user wants a different design, call list_invoice_templates. Show the available choices and plan access. Do not invent template IDs or bypass paid access.
  • Both invoice creation tools accept document_design: template, version, logo size (25–100), text size, spacing and table borders. Use font and color_schema for the font and colour. Omit these three options to preserve company branding. A partial design takes the chosen template's defaults.
  • Use update_invoice for invoice/quote edits and update_recurring_invoice for schedule edits. Send only changed fields in changes. Keep existing line IDs when editing items. A partial document design keeps the document's other saved controls; changing its template starts from that template's defaults. Explicit false, zero, blank strings and valid nulls are different from omitted fields.
  • Use update_invoice_settings only when the user wants to change future document defaults. Existing documents keep their saved design. Show-customer-number, show-contact-person, QR codes and online payment defaults are included.
  • Item rates use minor currency units (cents for EUR), including when copying a catalog product. The API calculates totals. Items also support description, unit, product/category IDs and line discounts.
  • For services, provide the requested service start/end dates. For goods, provide the delivery date. A recurring invoice takes interval, interval_count, starts_on (the first invoice date), payment_due_days and billing_in_advance; Norman sets the dates of each invoice from them.
  • Creation and edits accept payment links, QR codes, bank details, discounts, VAT notes, recipient/sender snapshots, and email/reminder settings. Use an empty VAT note only when the user requests no note; omission lets the API choose it.
  • In Germany, issuing an invoice books it at once: a GmbH/UG books the revenue on the service date, the self-employed count it when the payment comes. The invoice's payment takes that booking over.
  • Payment reminders are off unless the user asks for them. auto_reminders / autoReminders true on create_invoice, create_recurring_invoice or update_invoice makes Norman remind the client by the company's rule (paid plans). settings_on_overdue is an older field and sends nothing.
  • list_invoice_emails shows every email to the client with its delivery status. Email wording lives in list_invoice_email_templates / save_invoice_email_template; the reminder rule in get_invoice_email_settings / update_invoice_email_settings.
  • Set is_to_send / isToSend only when sending is requested or already authorized. Otherwise save the document without sending it. The same applies to mode "send" on a recurring invoice; the default "draft" sends nothing.

Corrections and delivery notes (documents made from an existing document):

  • To reverse an issued invoice in full, call cancel_invoice with the invoice id. Norman writes the Stornorechnung with the same lines, the next invoice number and a reference to the invoice, and marks the invoice cancelled. Confirm with the user first: a cancellation is a numbered document the client receives, not an edit. A draft, an issued or an overdue invoice is edited with update_invoice. A paid invoice cannot be edited: correct it with cancel_invoice or create_credit_note.
  • To correct part of an invoice (a wrong quantity, a price reduction, returned goods), call create_credit_note with the invoice id and the lines to credit. Without lines the whole invoice is credited. Norman prints "Rechnungskorrektur", never "Gutschrift", because since 2013 that word means self-billing under § 14 UStG. Use status: "draft" when the user wants to review it first.
  • Polish companies: a cancellation or a credit note is a faktura korygująca (its PDF says so). For an invoice in KSeF, Norman sends it to KSeF as a correcting invoice (KOR); when it cannot go yet, for example before KSeF accepted the invoice, the API refuses and says why: relay that message.
  • Lines on a Stornorechnung or a Rechnungskorrektur are positive, like on the invoice. The PDF prints every amount with a minus, and Norman turns lines typed with a minus around, so never negate amounts yourself.
  • To correct an invoice issued outside Norman, call create_invoice with document_type "cancel" or "credit_note" and pass preceding_invoice_number and preceding_invoice_date. The PDF prints "Storno zu Rechnung … vom …" and the e-invoice carries the reference. A correction prints no due date.
  • To make a Lieferschein, call create_delivery_note with the invoice id, or the id of a quote the client approved. It prints quantities and units only, no prices, and lands in the company's Files space under "Delivery notes". Pass lines for a partial delivery.
  • convert_offer_to_invoice makes a draft invoice from a quote. The quote stays, with the status "invoiced", and the invoice links to it. Issue the invoice with update_invoice (status "saved") before sending it.
  • To bill the same thing again, call duplicate_invoice with the invoice or quote id: it makes a draft dated today with the same lines, payment term and bank details. Move the service or delivery dates with update_invoice, then set status "saved" to issue it. A draft is never emailed or matched to a payment.
  • Both the PDF and the e-invoice XML name the source document, so never repeat the reference in message.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.