create_xero_payment
create_xero_paymentProposes recording a payment against an existing, AUTHORISED invoice in this Xero organisation - it does NOT touch Xero itself, and never will on its own. This queues a pending change that a human must explicitly approve (your Xero MCP connector - the exact link is this response's own approvalUrl field) before Xero is touched at all; you have no way to approve it yourself. Tell the user what you are proposing (which invoice, the amount and currency, which bank account, the date) and that it needs their approval in Invio before it goes anywhere - do not describe it as recorded, applied, or done. invoiceId must come from list_xero_invoices or get_xero_invoice (never invented). For the bank account, give EXACTLY ONE of accountCode or bankAccountName, both from list_xero_accounts (look for type BANK) - never invent either one, and never reuse an invoice line item's accountCode, which is very likely a revenue account, not a bank account. Use accountCode when that account has a real code; use bankAccountName (its exact name) when list_xero_accounts shows it as code: null - a bank account added through Xero's own "Add Bank Account" commonly has no code at all, and that is not a reason to guess one. UNLIKE EVERY OTHER CHANGE THIS CONNECTOR CAN DRAFT, a payment has no draft state in Xero at all - the moment a human approves this, it is applied immediately and the invoice is genuinely, immediately less owed. It can only be reversed by deleting the payment directly inside Xero itself - this connector has no tool that can do that, so make sure the user actually wants this recorded before they approve it. DATES: date is strict YYYY-MM-DD, so you always have to convert whatever the user actually said. A date carrying a month name ("8 Sep", "Sept 8th"), a weekday ("last Tuesday"), or an already-unambiguous full date ("2026-09-08") is yours to convert normally. A BARE NUMERIC date with no month name - "9/8", "08/09", "9-8" - is the one that is not: it means 9 August to most of the world and 8 September in the United States, and getting it wrong puts a payment a month out in a way nobody skimming the approval card will catch. This Invio account is based in a country that writes the DAY first, so read a bare "9/8" as 9 August, not 8 September. Say in plain words how you read it ("I read 9/8 as 9 August") so the user can correct you before they approve. If their own wording points the other way anywhere in the same request, ask them which they meant instead of picking.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date the payment was made, YYYY-MM-DD. Cannot be in the future - Xero can only record a payment that has already happened, never a scheduled one, and this is checked against the organisation's own current date (its own timezone, not the server's or your own). If the user wrote a bare numeric date with no month name ("9/8", "08/09"), do NOT settle it on your own judgement - it is 9 August to most of the world and 8 September in the US, and nothing downstream of this field can tell which you meant once it is a date. Follow the DATES instruction in this tool's description. | |
| amount | Yes | How much was paid, in the invoice's OWN currency - never convert it into a different one. Must not exceed what is currently still owed on the invoice (its AmountDue); a smaller amount is a valid PARTIAL payment and is allowed. | |
| currency | No | The currency you believe this payment is in, e.g. "NZD" - OPTIONAL, and NOT something this tool sets on the payment (a payment has no currency of its own; it is always in the invoice's own currency). If you provide this, it is checked against the invoice's actual currency and the draft is refused if they do not match - use it as a sanity check when the user names a currency, not to convert anything. Omit it if you are not sure. | |
| invoiceId | Yes | The Xero invoice this payment is against. Get this from list_xero_invoices or get_xero_invoice first - never invent one. The invoice must currently be AUTHORISED in Xero (a DRAFT invoice cannot receive a payment) and the amount must not exceed what is currently still owed on it (its AmountDue) - both are re-checked against Xero live, both when this is drafted and again when a human approves it, so a figure that was valid when you drafted it can still be refused later if the invoice has moved in the meantime (another payment, a credit note, a direct edit in Xero). | |
| reference | No | Free-text reference for the payment (e.g. "Direct debit", a bank reference). | |
| accountCode | No | This tenant's own chart-of-accounts code for the BANK account the money was received into (or paid out of) - e.g. "090". Get one from list_xero_accounts first (look for type BANK), never guess - not every bank account has one (list_xero_accounts shows code: null for an account Xero itself gave no code). Give EXACTLY ONE of accountCode or bankAccountName: accountCode when the account has a real code, bankAccountName (its exact name instead) when it does not. Whichever you give, it must be a BANK account and ACTIVE in Xero - both are checked live, and the draft is refused with the real reason if either is not true. | |
| organisation | No | The Xero organisation to use, by its display name. Only needed if this connection reaches more than one organisation - omit it when there is only one. | |
| bankAccountName | No | This tenant's own exact name for the BANK account, for when it has no code in Xero at all (see accountCode's own description). Get it from list_xero_accounts first (look for type BANK) - it must match a real BANK account's name exactly (matched case-insensitively, but never a guess, an abbreviation, or a partial name). Give EXACTLY ONE of accountCode or bankAccountName, never both, never neither. |