# Customer communications Customer emails are sent by Alunta on the team's behalf to the team's end customers. Global team email choices, additional recipients on an individual customer, text customization, branding, and internal team notifications are separate settings. ## Choose the customer’s language Customers can use Danish, English, German, Italian, French, Swedish, Norwegian Bokmål or Spanish. Set **Language** on the customer, or let the customer save it in their authenticated customer portal. **Automatic from country** uses the customer’s country and falls back to English for an unmapped country. Choosing a language does not change country, currency, VAT or payment method. The customer API and AI tools support the same preference; omitting it on an update preserves it, while `null` returns it to automatic. A checkout language choice is remembered for the purchase and for a newly created customer. Changing the display language on a public link does not edit an existing customer’s account. If checkout matches an existing customer by email, their saved preference remains in place. New invoices use their recipient’s language. An existing invoice keeps its original document language after a preference change, and an attached credit note follows the original invoice. An email already admitted for sending keeps its captured language on retry; changing language on a prepared payment reminder requires renewed approval. Alunta’s local invoices, portal, checkout and customer emails support all eight languages. Text written by the team remains as written. An accounting-system PDF follows that provider’s settings: Dinero supports Danish and English, so other languages use English for its PDF. Other accounting PDFs retain their configured layout. Hosted payment windows use the provider’s available languages; PensoPay uses Danish or English, and Cost+ uses English for Italian and Spanish. ## Choose email types and recipients Go to **Settings → Customer emails** for global choices. Enable or disable the supported email types there. Some required portal messages are locked. On a customer, add additional recipients and choose which invoice and payment emails they should receive. An additional recipient does not receive a portal login link, and an address matching the customer's primary address is not used twice. For automatic delivery, the global choice determines whether the email type is sent and customer preferences determine additional recipients. For a manual **send now**, the operator reviews and confirms an explicit recipient list; that action bypasses the automatic preference gates and sends to the confirmed list. The portal login link still goes only to the customer. ## Edit the text Choose an email type, one of the eight languages, and editable fields such as subject, greeting, introduction, or closing. Each language has its own customization; if none is saved, Alunta uses the built-in text for the customer's selected language. Insert fields only from the field picker. Open the preview with example data, and reset the selected language if you want its standard text again. System-controlled buttons, amounts, attachments, and required sections remain part of Alunta's email. Plan and subscription names and other text written by the team are not translated. ## Reminder before a subscription ends The **Reminder before a subscription ends** email type is off until the team switches it on under **Settings → Customer emails**. A team that has never saved a choice does not send it. In the same place the team chooses how many days before the end date it is sent (1-180, default 30). That number is stored independently of whether the email is on and of any customized texts. A scheduled job runs every hour. From 09:00 in the team's timezone it sends the email for subscriptions whose end date is exactly the chosen number of days ahead and that the customer or the team has cancelled. It is not sent for subscriptions that ended because of a failed payment, for card subscriptions without a saved card, for subscriptions of a deactivated customer, for deleted customers, or when the account is closed. If a customer has several subscriptions with the same end date, they go in one email. A customer gets at most one email per end date, even if the subscription is resumed and cancelled again to the same date or the team changes the number of days. The email is only sent on the sending day itself (end date minus the number of days); if the number of days is changed so that day has already passed, it is not sent retroactively. If the customer has no email address when the email is due, sending is tried again later the same day. Once sending has begun and fails, it is not retried. Older cancellations from before the cancellation reason was recorded are covered too, as long as they still have a future end date. An end date that came with an import (for example a fixed term from e-conomic) is a contract term, not a cancellation, and gets no reminder. The email goes only to the customer's own email address, never to additional recipients, because it contains a one-time link to the customer's login. The customer's opt-outs and test-account routing apply. The text can be customized and previewed like the other emails; the **Resume subscription** button is system-controlled. The button opens a signed link to a confirmation page. Opening it changes nothing and logs nobody in, because mail scanners open links too. The page lists the subscriptions with **Resume subscription** for each and **Go to the customer portal**. With one press the link is used (it works once), the customer is logged in to the customer portal, and a chosen subscription is resumed by clearing its end date, just as when the customer does it in the portal. The resume can be refused (for example when the account is closed), and a message is shown. The link only logs in while at least one of its subscriptions can still be resumed; when they have all been resumed, have ended or have been deleted, the page says there is nothing to resume and offers the portal login instead, and the link is not spent. A used link shows a page with a way to the portal or the login page. After the end date, an otherwise valid link shows a page saying it has expired, with a way to the portal login. Teams that want to control timing or wording themselves can use webhooks (`subscription.cancelled` carries `end_date`). ## Branding and fixed attachments In invoicing settings, choose the team's logo and header style for Alunta invoices and customer emails. This does not change a PDF downloaded directly from e-conomic, Dinero, or Billy. Fixed attachments for invoice emails are locked when the email is created. A new email uses the current list; a retry of the same email uses the files already fixed to it. ## Team notifications A team notification goes to business users by email, Alunta, or Slack. It is not a customer email and not a webhook. The reminder before automatic invoicing helps the team update usage; it is not a dunning message to an end customer. ## Questions **Can I write the whole invoice email myself?** Only fields the email type makes editable; facts and system-controlled sections remain. **Why did an accountant not receive an email?** Check the customer's recipient choices and that the email type is still enabled globally. **Why did the logo not change an accounting PDF?** That PDF is produced by the accounting system and has its own layout. ## Customer emails from test and partner accounts Customer emails sent from a test account or a partner account are redirected at send time to that account's verified owner address. This applies to the account's own customers, including manual sends, additional invoice recipients, CC and BCC. Subjects carry `[TEST]`. Each sample customer has a different `demo.invalid` address; the selected customer's portal login link is delivered to the owner. A partner's other, ordinary operating accounts keep their own email behavior; each account's mode controls its customer email routing. Automatic emails to customers whose address is on the reserved `.invalid` domain (the sample customers have `@demo.invalid` addresses) are suppressed. This covers, for example, invoicing runs, reminders, payment failures and confirmations when a subscription is created. Emails a person explicitly asks for are still redirected to the owner: Send buttons, manual reminders, offers, credit notes, one-off invoices, the recollect link, the customer portal login link and `POST /v1/invoices/{uuid}/send`. When all recipients are on `.invalid`, an automatic email is suppressed; a manual send is delivered as a copy to the owner. Suppressed emails are not sent later. A test or partner account that has not been used for 30 days (no signed-in use by a member, no API call and no AI access via MCP) sends no customer emails until it is used again. Emails suppressed in the meantime are not sent afterwards. No customer email is sent without a valid, verified owner address. Manual sends show an error, while queued sends are suppressed. Later verification does not automatically resend old messages. History preserves the intended recipient and records the actual recipient after transport confirmation; historical rows are not rewritten. Separate invoice recipients can result in several test emails to the owner. Alunta's own login, invitation and owner/member emails retain their normal behavior. Redirection does not change payments or other integrations, and does not guarantee inbox placement.