File a pending recurring-invoice draft (human approves in Taokeh)
create_recurring_invoice_draftFILES A PENDING DRAFT ONLY — NOTHING IS CREATED UNTIL A HUMAN REVIEWS AND APPROVES IT IN TAOKEH. Propose a NEW recurring invoice — a billing schedule that issues the same invoice to the same customer every month, quarter or year (a retainer, a subscription, a maintenance contract, rent). This does NOT create anything: it files a pending DRAFT the owner reviews and approves; only that tap saves the schedule. Give the customer (customerId from resolve_customer, or customer as an EXACT existing customer name — this tool never creates a customer), the lines (each a real catalogue product by productId or exact sku, with the quantity and the agreed unit price that will be billed EVERY cycle), the cadence, and the startDate — whose day of the month becomes the billing anchor (a 31st anchor lands on the 28th/29th/30th in shorter months). Optionally endDate, maxOccurrences, title, notes and paymentMethod (CREDIT = the customer owes it and pays later, CASH = settled at issue; these book differently, so ask rather than guess). A CASH schedule's money is booked where the schedule's "Paid into" says: the owner picks it on the schedule's own page, never this tool, and a schedule proposed here starts on the default (the Cash account for a walk-in customer, otherwise the account the company books cash sales to, usually its main bank). ⛔ WHAT IT CANNOT DO: it cannot set issueMode: "auto" — a schedule you propose files an invoice DRAFT each cycle for a person to approve, and nothing proposed through this connector may buy itself the right to post invoices unattended; the owner switches that on themselves if they want it. It cannot set MFRS 15 revenue spreading (recognition), which is an accounting-policy decision on the schedule's own page. It cannot set the next issue date directly — that is derived from the start date and the cadence, and the review page tells the owner the exact date the FIRST invoice would be issued before they approve. BE HONEST: never guess a contracted price or a start date — leave the schedule unproposed and ask.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | What gets billed every cycle. Every line must be a real catalogue product. A line carrying Taokeh's printed per-foot or per-piece note (like "(400' @ RM 1.60/feet)") is refused: a schedule holds no size or tally, so it would bill without its rounding line every cycle. Raise those invoices with create_invoice_draft in their filed form. On an update, such a line already on the schedule may be sent back unchanged. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed. | |
| notes | No | A SHORT reviewer note, in the reviewer's language: what this schedule bills and what they should double-check. | |
| title | No | A short label for the schedule, e.g. 'Monthly retainer — Acme'. Optional; it never prints on the invoice. | |
| cadence | Yes | ||
| endDate | No | Stop issuing after this date. Optional. | |
| customer | No | An EXACT existing customer name. A name that matches nobody is refused — this tool never creates a customer. | |
| startDate | Yes | The first billing date. Its DAY OF THE MONTH becomes the anchor for every later cycle. A date in the past does not backfill — the first invoice lands on the first cycle on or after today. | |
| customerId | No | The customer id from resolve_customer. Give this OR `customer`. | |
| needsReview | No | Set true when something gave you pause — a price the user was unsure about, a start date you inferred. | |
| paymentMethod | No | CREDIT (default) = the customer owes it. CASH = settled at issue. Ask the user; these book differently. | |
| maxOccurrences | No | Stop after this many invoices. Optional. |