# Alunta product areas and common workflows ## Customers, plans, and subscriptions A team can create end customers and describe what it sells as plans. A plan may use fixed, usage-based, or tiered pricing and can include a trial, discount, custom fields, and different renewal intervals. When an end customer buys a plan, Alunta creates a specific subscription. The subscription has its own price, payment method, start date, and lifecycle. Several plans can be sold together as a subscription bundle, but each subscription can later change or end independently. ## From subscription to invoice Alunta prepares future subscription transactions from the subscription periods, price, and any usage data. Prepared entries can be collected on an invoice. A one-off invoice can also be created without a subscription. An invoice describes the amount due; payments describe amounts that have actually been recorded. An invoice can therefore be unpaid, partially paid, or paid and can have several payments. Refunding and crediting are separate operations and must not be confused with deleting the original invoice. ## Checkout and self-service Checkout can sell subscriptions, subscription bundles, and payable one-off invoices. The end customer can enter information required by the team, choose from payment options made available by the team, and receive a customized confirmation. The exact checkout and self-service experience depends on the team's plans, apps, payment setup, and settings. Product documentation can explain the available capabilities, but the current setup must be checked with the MCP tool `get_apps_overview` and relevant team tools. ## Payments, accounting, and delivery Alunta supports bank transfer and manual registration as well as payment integrations such as OnPay, Stripe, QuickPay, PensoPay, MobilePay, and Leverandørservice. Payment methods do not all support the same purchases or subscription flows, and an integration must be connected and configured for the specific team. Invoices, customers, products, and payments can be synchronized to a connected accounting system. Supported accounting integrations include e-conomic, Dinero, Billy, and Uniconta. Invoices can also be delivered by regular email or, when the requirements and setup are satisfied, through EAN/NemHandel. ## Data, analytics, and automation Custom fields and usage parameters make it possible to store domain-specific customer information and record the usage on which pricing depends. Dashboards and analytics can show revenue, MRR, growth, churn, invoices, and payment status. Alunta Radar can monitor relevant public company information for eligible customers. Teams can use notifications, Slack, the public API, webhooks, and third-party integrations to react to events. The API and webhook contracts are available in the public integration guide and OpenAPI specification. ## Reseller and installments A reseller (payer) is a customer that pays selected subscriptions on behalf of other customers and receives one consolidated invoice for them. Coverage is set per subscription, so a reseller can pay all, some or none of a customer's subscriptions. Installments split one service period of a flat-rate subscription with a longer-than-monthly interval into slices with their own bill dates; each slice is charged or invoiced on its own and settles separately. Your own AI can see each app through one tool. `get_reseller_overview` lists the resellers (customer uuid and name) with how many customers each pays for, how many of their subscriptions it covers, and the monthly value of the covered subscriptions per currency; it needs the Customer details setting and does not list the customers behind a reseller. The monthly value is the same figure the Reseller tab of a customer shows as the total per month: only subscriptions that are billable today count (not future-start, trial, paused or usage-based ones), although those still count as covered subscriptions. Switching the Reseller app off removes every payer link. `get_installment_overview` shows how many subscriptions pay in installments, all slices by state (paid, invoiced and not paid yet, due, upcoming, not collected after a payment failure ended the subscription, and outside the subscription's billing period so never billed), what is outstanding per currency excluding VAT, and the next slices to fall due by subscription uuid, bill date and amount. A due slice is one whose bill date has arrived; it is not proof that it is late or failed, because the charge or invoicing run may not have reached it. Neither tool returns contact details, addresses, card or provider data, or invoice and payment ids. ## Radar and the health check Radar checks the company register every day for eligible customers (a CVR number and a running subscription) and records a finding when something changes. A finding is an observation that may need follow-up, not a decision about the customer. The health check compares the team's invoices and their synchronization with e-conomic and reports differences; a finding is a difference to review, not proof that an invoice or the books are wrong, and a case groups the findings about one invoice. The health check also shows the current small-remainder tolerances and the separate DKK reminder minimum, with the reminder system's activation status. A documented, reconciled remainder within tolerance requires no further payment follow-up in Alunta; it may still remain in e-conomic. These thresholds do not approve invoice or VAT differences or change earlier findings. An explained historical rounding difference is not itself proof of payment. The result shows when the latest completed check ran; documents and payment checks may have changed since then. Where the saved evidence is sufficient, the case explains whether the next step is review by your bookkeeper or clarification of Alunta's reconciliation. Open the invoice or credit note and its accounting details to review the payment check. Running a new health check does not itself run a new payment reconciliation. A missing confirmed document link does not prove that the document is absent from e-conomic. Technical error details can be expanded, and cases containing only explained historical VAT rounding have a separate label. “Mark as known” acknowledges the review and changes neither payments nor settlement. Your own AI can see each app through one tool. `get_radar_overview` shows the monitored, paused and unsupported watches (unsupported means the register does not find the company, so the CVR number has to be corrected), the open findings by type and severity, the company status behind the open company status findings (for example under bankruptcy, bankrupt or ceased, as a fixed code), the estimated affected annual subscription value of the customers with open findings (what they pay per year, not an expected loss, and unavailable when an exchange rate is missing), the findings detected in a period, and the customers that need follow-up with the type and severity of the finding and, for a company status finding, its status code; the customer list needs the Customer details setting, and the tool is only available while the Radar subscription is active. It deliberately returns no register text, only that fixed code, so for the facts behind a finding the customer has to be opened in Radar. `get_health_check_overview` shows when the health check last ran and how that run ended, how many cases and findings are open (from the latest completed run, minus the ones the team marked as known) by severity, check and category, how many findings resolved themselves in a period, and the open findings with the title the app shows; the invoice number of a finding needs the Invoice details setting, and the tool is only available while the app is switched on. A new difference in e-conomic or in an invoice shows up only after the next run. Neither tool returns amounts compared with e-conomic, notes or user names. ## What AI Access can combine `search_product_knowledge` supplies general product knowledge, the API contract, and change history. Other MCP tools supply current, team-scoped metrics and app states. Details about specific end customers or invoices are available only when an administrator has explicitly enabled the corresponding data categories. A team can additionally approve individual customer custom fields for read-only listing and filtering; unapproved and newly created fields stay private. Customer lists omit custom-field values unless the caller explicitly selects approved field keys after reading the field catalog. A complete answer should therefore combine general documentation with the team's current state. A capability that exists in Alunta is not necessarily enabled, available, or fully configured for the selected team.