Terms of Service

Effective date: 15 September 2026 · Version: 2.2

These terms were drafted in Danish. The Danish version is the legally binding one — see section 17.

1. The parties and the agreement#

1.1 The parties. The invoia service (the "Service") is provided by Creo Digital, CVR no. DK45246132 ("invoia", "we", "us"). The agreement is entered into between invoia and the business that creates an account (the "Customer", "you").

1.2 What the agreement consists of. The agreement consists of these terms, the Privacy Policy and the price and subscription information displayed in the Service when the subscription is created. In the event of conflict, these terms prevail, save that section 9 prevails over the other sections as regards the processing of personal data.

1.3 Entry into force. The agreement takes effect when the Customer creates an account. By creating an account, the Customer accepts these terms.

1.4 Communication. Notices under these terms are given in writing by email in Danish or English. invoia can be contacted at support@invoia.io. Notices to the Customer are sent to the email addresses registered for the account's administrators, and the Customer is responsible for keeping those addresses up to date.

2. What the Service is — and is not#

2.1 What the Service does. invoia is a web-based service for invoicing and ongoing revenue recognition. The Service runs on top of the Customer's own accounting system — a Dinero organisation or a Danish e-conomic agreement (both Visma) — which the Customer must hold and connect itself. Connecting Dinero requires a Dinero Pro subscription on the organisation; see 2.6 for e-conomic. In the Service the Customer can, among other things:

• mirror and edit debtors and products from the Customer's accounting system,
• create one-off invoices and recurring series (monthly, quarterly, semi-annual and annual),
• register hours and completion per invoice line, per user, per month,
• have earned revenue, work in progress and deferred revenue calculated,
• have a monthly accrual voucher posted per customer,
• view reporting per user, customer and product,
• issue credit notes, which are the only way to correct an issued invoice,
• use machine access under section 7.

2.2 invoia is not an accounting system. invoia does not keep books and holds no general ledger. The Service creates and posts invoices, credit notes and accrual vouchers in the Customer's own Dinero organisation. The bookkeeping basis therefore sits in the Customer's own accounting system, not with invoia. invoia's data is a copy. The Customer's relationship with Visma is a separate agreement between the Customer and Visma on Visma's terms and is not covered by these terms.

2.3 Dinero delivers the invoice — invoia does not. When an invoice is issued, it is posted in the Customer's Dinero organisation, after which Dinero sends the invoice document to the Customer's end-customer by email or as an e-invoice. invoia does not itself send invoices to the Customer's end-customers. invoia's own emails go solely to the Customer's own users.

2.4 invoia makes no VAT or accounting determinations. Invoice lines are sent to Dinero with the ledger account numbers recorded on the Customer's own products. Neither a VAT code nor a VAT rate is sent; VAT is derived by Dinero. The VAT summary that can be displayed before posting reproduces Dinero's calculation from mirrored reference data; it is a display and not a warranty, and it marks itself as unavailable rather than guessing when the basis cannot be derived. Accrual vouchers carry no VAT. The accounts for revenue, work in progress and deferred revenue are chosen by the Customer. Recognised revenue is a calculation on the information the Customer's own users enter — hours, completion, agreed value and rates — and contains no accounting judgement.

2.5 No advice. invoia does not provide tax, accounting, audit or legal advice. Nothing in the Service, in its calculations or in its displays constitutes advice, and the Customer may not rely on it as such. The Customer is itself responsible for complying with the Danish Bookkeeping Act, the VAT Act and other legislation, including for checking what the Service posts.

2.6 e-conomic in place of Dinero. The Service can be connected to e-conomic instead of Dinero. That is a full connection on a par with Dinero: the Service creates and posts invoices, credit notes and accrual vouchers in the Customer's own e-conomic agreement, e-conomic itself sends the invoice document to the Customer's end-customer by email or as an e-invoice, and the Service mirrors the agreement's debtors and products so an invoice line can be built without re-typing them. Where 2.2–2.5 name Dinero, the same applies to e-conomic where the Customer invoices through e-conomic. Only Danish e-conomic agreements can be connected; an agreement from another market is refused at connection. One difference from 2.4 should be stated: e-conomic requires every invoice to name the debtor's VAT zone, and the Service states the zone the debtor is in at e-conomic — neither a VAT code nor a VAT rate is sent, and VAT is still derived by e-conomic.

2.7 What the Service does not include. The Service does not include payment follow-up, debtor status, dunning or payment reminders; any form of bank connection, bank reconciliation, voucher processing or automated posting of vouchers; VAT filing, payroll, purchase vouchers or a document archive; project or resource planning; and no export function, see 12.4.

3. Who the Service is offered to#

3.1 Businesses only. The Service is offered solely to businesses (erhvervsdrivende) acting in the course of their trade. The Service is not offered to consumers.

3.2 The Customer's warranty. By creating an account, the Customer warrants that the Customer is a business, that the person creating the account is authorised to bind the Customer and is at least 18 years of age, and that the information the Customer provides is correct and kept up to date.

3.3 No verification is performed. invoia does not verify any of this. No check is made of CVR number, the existence of the company, VAT number, authority to bind or age at registration, and a VAT number provided is not validated. The requirement in 3.1 is contractual only, and responsibility for meeting it rests with the Customer.

4. Account, users and roles#

4.1 Account and roles. One account constitutes one delimited workspace. Each user on the account holds one of two roles: administrator or standard user. The administrator can invite, edit and remove users, connect and disconnect accounting connections, create and revoke API keys, register webhook endpoints, manage subscription and payment, and view reporting for the whole account. The standard user can register their own work and sees only those integrations an administrator has expressly granted access to.

4.2 Access. Access to the Service requires two-factor authentication for each user.

4.3 The Customer's responsibility for the account. The Customer is responsible for everything that happens under the Customer's account, including every act by the Customer's users and every act performed with credentials issued to the account. The Customer must ensure that credentials are kept confidential and are not shared, and must remove users who are no longer to have access.

4.4 Warning: removing a user deletes that user's registrations. When a user is removed from the account, that user's registered hours and completion figures, together with the user's assignments to invoice lines, are deleted at the same time and irreversibly. That information forms part of the basis for revenue recognition already performed. No warning is given in the Service, no copy is taken, and the act cannot be undone. The Customer must secure the records it needs before removing a user.

5. Subscription, price and payment#

5.1 Form of subscription. There is one subscription per account with one product: a seat per user, billed monthly. There are no packages or tiers, no annual subscription and no usage-based billing. The price is stated in the Service when the subscription is created and in the subscription settings. All prices are exclusive of VAT.

5.2 Number of seats. The number of seats equals the number of user profiles on the account, with a minimum of one. Pending invitations are not billed. The number is updated when an invitation is accepted, when a user is removed, and when the subscription page is loaded.

5.3 Free trial. A 14-day free trial is granted, one per account. A payment card is required at signup, and the payment step cannot be skipped. Nothing is charged on the day of signup. At the end of the trial the subscription converts automatically to a paid subscription unless cancelled beforehand. No new trial is granted on re-subscribing after a cancellation.

5.4 Payment. Payment is made by payment card. Direct debit, bank transfer and payment against invoice are not offered. Card details are entered directly with invoia's payment provider (Stripe) and are not processed in invoia's own systems.

5.5 Changes in the number of seats. If the number of seats changes during a period, the difference is calculated proportionally for the remainder of the period. Both charges and credits are settled on the next invoice and are not billed immediately.

5.6 Cancellation. The subscription may be cancelled by an administrator. Cancellation takes effect at the end of the paid period, and the Customer retains access until then. A cancellation may be undone until the end of the period.

5.7 No refunds. Amounts paid are not refunded, including on cancellation mid-period or on non-use. The only proportional adjustment is the one that follows from 5.5.

5.8 Failed payment. If a payment fails, the Customer retains access while the payment is retried. If the subscription ends, access is limited to the subscription settings; the Customer's users can still sign in. The Customer's data is not deleted automatically, see 14.3.

5.9 Price changes. invoia may change its prices. Price changes are notified under section 15 and take effect no earlier than the start of the following billing period.

5.10 Billing information. The Customer is responsible for providing a correct company name, billing address, billing email address and, where applicable, VAT number. This information is not verified by invoia.

6. Automated issuance and posting#

This section describes the Service's most important characteristic and its most important risk. The Customer should read it before connecting an accounting connection.

6.1 The Service acts unattended. The Service performs scheduled runs with no one signed in:

• every day at 04:00 (Europe/Copenhagen) a run posts due invoices in the Customer's Dinero organisation and has Dinero deliver them to the Customer's end-customers,
• the same run issues an invoice that has no fixed issue date as soon as every line on the invoice is registered as 100 % complete; the invoice is then dated with that day,
• on the 1st of each month at 04:00 a run posts the month's accrual voucher per customer in the Customer's Dinero organisation. There is no manual month-end close.

The runs use the access to Dinero the Customer granted on connection and are performed on the Customer's behalf without any contemporaneous act by the Customer. In addition, a user can issue an invoice manually. A manually issued invoice is likewise subject to 6.3.

6.2 Automatic issuance is on by default. Every invoice is created with automatic issuance switched on, regardless of how the invoice is created. To hold an invoice back, the Customer must switch automatic issuance off on that individual invoice before the run takes place. There is no master switch — not per account, not per integration and not globally — and the automation cannot be paused. The only way to stop all runs is to disconnect the accounting connection, see 14.2, which at the same time deletes the Customer's data in the Service, see 9.12(a).

6.3 Posting is final. Once an invoice has been posted in Dinero, it is an entry in the Customer's own accounts. invoia can neither cancel, delete nor amend it. The only way to correct it is a credit note, which is itself posted. The same applies to posted accrual vouchers.

6.4 Posting and delivery are separate. Posting and delivery are two steps. If posting succeeds but delivery fails, the posting is not reversed. An invoice that has been posted but not delivered is a foreseen and normal outcome. No guarantee is given that an invoice will be delivered. Delivery is made to the email address registered for the end-customer in invoia, and that address takes precedence over the address on the contact in Dinero. An incorrect or outdated address in invoia therefore determines where a posted invoice ends up. The Customer warrants that the delivery details registered are correct and up to date.

6.5 Closed periods. If the accounting period an accrual voucher belongs to is already closed in Dinero, the Service deletes the draft for the closed period and posts the entry in the following month instead. The Customer is, so far as possible, informed by a notice in the Service; the notice is best-effort and no guarantee is given that it appears. No email is sent and no prior approval is required. The Customer is responsible for assessing the accounting effect of such a shift of period.

6.6 Failures in a run are not notified. invoia gives no notice when an automated run fails, skips an invoice or fails to deliver an invoice. No email and no other notification outside the Service is sent. Failures and delivery errors can only be established in the Service, and only when someone opens it.

6.7 The Customer's configuration and review. The Customer alone bears responsibility for the configuration: customers and their delivery details, products, account numbers, prices, recognition method, series, hours and completion. The Customer must designate at least one responsible person who

• reviews the Service regularly and no later than the first business day after a run in which invoices may have been issued,
• reviews the Service at the beginning of each month after the accrual run, and
• reconciles what has been posted against the Customer's own accounts before those accounts are relied on, reported or filed.

The Customer accepts that automated issuance and automated posting take place at the Customer's risk, and that invoia is under no obligation to check the content of what is issued or posted.

7. Machine access: API, MCP and webhooks#

7.1 What is offered. The Service can be accessed by machine through a REST API, through an MCP server for AI assistants and other clients, and through webhook endpoints. Machine access is part of the Service and is expressly permitted.

7.2 API keys. API keys are created and revoked by an administrator in the Service. A key is shown once on creation and cannot be shown again. API keys do not expire. A key is valid until it is revoked.

7.3 The reach of a key or token. A key or token with write permissions can post invoices in the Customer's Dinero organisation and have them delivered to the Customer's end-customers in a single call and with no further confirmation step. Access granted to an AI assistant through MCP is granted as a whole for the permissions the client requests; access cannot be narrowed permission by permission on the approval screen.

7.4 Acts are attributed to the Customer. Every act performed with the Customer's API key or access token is, as between the parties, deemed to be the Customer's own act. This applies also where the act is performed by an AI assistant, an automated system or a third party to whom the Customer has granted access. invoia cannot distinguish a human from a machine and does not verify that a human has approved the individual act.

7.5 The Customer's obligations. The Customer must

• keep keys, tokens and signing secrets confidential,
• use a separate key per integration or vendor,
• revoke an API key immediately in the Service when a person leaves, when a vendor relationship ends, or where the key may have become known to unauthorised parties, and, for accesses that cannot be revoked in the Service, see 7.9, request revocation from invoia without delay,
• register only webhook endpoints the Customer itself controls, and
• not pass access on more widely than the purpose requires.

7.6 invoia's right to intervene. invoia may without notice revoke keys and access, disable endpoints and limit or refuse machine calls where necessary to protect the Service, other customers or third parties, or where the Customer is in breach of 7.5.

7.7 Rate limits. invoia may limit the number of calls. invoia does not warrant that such a limit operates in all cases, and the Customer must not design its integrations on the assumption that invoia limits the Customer's own traffic.

7.8 Webhooks. Webhook endpoints and event types can be configured in the Service, but webhook events are not delivered today. The Customer must not rely on receiving them and must not use webhooks as a control or alerting mechanism, including not for detecting failures under 6.6. The configuration may remain in place, but it constitutes no undertaking as to delivery.

7.9 Accesses that cannot be revoked in the Service. The Service does not show which clients hold an active OAuth grant to the Customer's account, and contains no function for revoking such a grant. Only API keys can be revoked by an administrator. If the Customer wants an OAuth grant revoked, the Customer must request this from invoia at support@invoia.io, see 7.6. An access is bound to the connected accounting connection; if the connection is disconnected, see 9.12(a), there is no longer any data to reach, but disconnecting does not itself revoke the access granted.

8. Acceptable use#

8.1 The Customer must not. The Customer must not

• use the Service in breach of the law or issue invoices the Customer has no basis to issue,
• attempt to access data belonging to other customers, or circumvent the Service's access controls,
• probe, scan, load-test or attack the security of the Service without prior written agreement,
• resell the Service or make it available to third parties as a service in its own right,
• copy, decompile or attempt to derive the Service's source code beyond what mandatory law permits,
• give false information about its identity or about on whose behalf it is acting.

8.2 Machine use is permitted. For the avoidance of doubt: machine access through the API and the MCP server, including access the Customer grants to third-party tools and AI assistants, is permitted and governed by section 7.

8.3 Suspension. invoia may suspend access in whole or in part on material breach of this section, or where continued operation entails a risk to the Service, to other customers or to third parties.

9. Data processing terms (Article 28)#

This section constitutes the parties' data processing agreement under Article 28 of the General Data Protection Regulation.

9.1 Roles. For the personal data the Customer has processed in the Service in connection with invoicing and revenue recognition, the Customer is the controller and invoia is the processor. For invoia's processing of information about the Customer's users as registered users of the Service and about the Customer as a paying customer — registration, authentication, security, billing of the subscription and support — invoia is the controller; that processing is described in the Privacy Policy.

The allocation of roles follows the category of data and not the individual data table. The same user profile is both invoia's authentication identity, where invoia is the controller, and the Customer's employee record with hourly rate and monthly productivity, where the Customer is the controller.

9.2 Subject matter, duration, nature and purpose. The subject matter is the processing necessary to provide the Service as described in section 2. The processing consists of collection, recording, storage, structuring, mirroring, calculation, display, disclosure to the Customer's own accounting organisation, and deletion. The purpose is invoicing, revenue recognition, registration of work, reporting and the machine access the Customer itself enables. The processing runs from the creation of the account until the agreement ends and deletion has been carried out under 9.12.

9.3 Categories of data subjects and of personal data.

(a) The Customer's end-customers (debtors) and their contact persons: name, attention person, email address, telephone number, address, postcode, city, country, website, CVR/VAT number, EAN, SE and P numbers, an indication of whether the contact is a private individual, payment terms, delivery method, and preferred currency and language. The information comes both from what the Customer's users enter and from a daily mirroring of the Customer's entire active debtor register in Dinero. The mirroring retrieves all active debtors — not only those the Customer uses in the Service — and Dinero prevails in the event of conflict.

(b) The Customer's own users and employees: name, email address, role, hourly rate and rate overrides, distribution percentages, registered hours and completion per month, and a record of who registered on whose behalf.

The Service is not designed for special categories of personal data under Article 9 of the Regulation or for data relating to criminal convictions and offences under Article 10. The Customer must not enter such data into the Service's free-text fields.

9.4 The Customer's own employees. The Customer is the controller for the processing of information about the Customer's own employees in the Service. The Customer is aware that the Service's account-wide reporting shows registered hours and recognised revenue per named employee per month for up to 60 months, and that the reporting is available to any administrator on the account. There is no opt-out, no restriction and no notice in the Service. The Customer is responsible for having a valid legal basis for this processing and for meeting its own duty to inform its employees, including under the Danish Data Protection Act's rules on processing in the employment context.

9.5 Instructions. invoia processes personal data only on documented instructions from the Customer. These terms, the Customer's use of the Service's functions and the Customer's own configuration together constitute the Customer's complete documented instructions.

The Customer is aware that the Service contains no settings by which the Customer can limit which fields are stored, which sub-processors are used, or how long information is retained. Instructions beyond the functionality of the Service require separate written agreement, and invoia may decline them or make them subject to separate payment.

invoia informs the Customer if, in invoia's opinion, an instruction infringes the General Data Protection Regulation or other data protection legislation.

9.6 Confidentiality. invoia ensures that the persons authorised to process personal data for the Customer have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that access is granted only to the extent necessary.

9.7 Security. invoia implements appropriate technical and organisational measures under Article 32 of the Regulation. The measures are described at /security. invoia may change the measures over time; a change must not materially lower the overall level of protection.

9.8 Sub-processors. The Customer hereby gives general written authorisation for invoia's use of sub-processors. On the entry into force of these terms, the following are used for the processing invoia carries out for the Customer:

In addition:

• Visma (Dinero) is the Customer's own accounting system. invoia transfers information to it on the Customer's instructions. The relationship between the Customer and Visma is governed by the Customer's own agreement with Visma and is not covered by this agreement. The same applies to Visma (e-conomic) if the Customer establishes an e-conomic connection.
• Where the Customer grants a third party access under section 7, including an AI assistant, that disclosure is made at the Customer's own decision and at the Customer's risk. Such a third party is not invoia's sub-processor.
• Stripe processes the Customer's billing information. That processing takes place with invoia as controller, see 9.1, and is not covered by this agreement.
• Resend is used for invoia's own transactional email to the Customer's users — verification codes, invitations and password resets. That processing takes place with invoia as controller, see 9.1, and is not covered by this agreement.
• Sub-processors used solely for invoia's own processing as controller are listed in the Privacy Policy.

invoia undertakes to impose on every sub-processor data protection obligations equivalent to those set out in this agreement, and invoia remains liable to the Customer for the sub-processor's performance of its obligations.

invoia may add or replace sub-processors. invoia gives the Customer at least 30 days' notice before a change takes effect, by notice to the account's administrators and by updating the list above. Within the notice period the Customer may object in writing, stating reasons. If the parties cannot find a solution within a reasonable time, the Customer may terminate the agreement with effect from the time the change takes effect, without this constituting a breach by either party and with no remedy other than termination.

9.9 Transfers to third countries. Several of the sub-processors used are international providers, and processing outside the EU/EEA may occur. invoia can today state with certainty the place of processing for the database, which is operated in Ireland; for the other sub-processors invoia cannot state the place of processing with certainty. invoia undertakes to ensure that any transfer to a third country takes place on a valid transfer mechanism under Chapter V of the Regulation, and on written request will state which mechanism applies to each sub-processor.

9.10 Assistance with data subject requests. The Service contains no self-service function for access, extraction, rectification or erasure in respect of individuals. invoia therefore assists the Customer manually and taking into account the nature of the processing in responding to requests for access, rectification, erasure, restriction, objection and data portability. Requests are sent to support@invoia.io by an administrator on the account. Assistance is provided within a reasonable time; no response deadline has been agreed.

The Customer is aware of the following limitations, which follow from how the Service is built:

• An end-customer who has been invoiced through the Service cannot be deleted individually. Invoices refer to the customer record, and the record in Dinero cannot be deleted for as long as postings refer to it. Such a record can only be removed by disconnecting the accounting connection under 9.12(a), which deletes the entire data set.
• Information posted in the Customer's Dinero organisation can neither be amended nor deleted by invoia. It belongs to the Customer and forms part of the Customer's own accounting records.
• Debtor information is mirrored daily from Dinero, which is the leading source. A correction made in invoia alone is overwritten at the next mirroring. Corrections must therefore be made in Dinero.

9.11 Personal data breach. invoia notifies the Customer without undue delay after invoia becomes aware of a personal data breach affecting personal data processed for the Customer. The notification is sent to the account's administrators and contains the information invoia holds at that time; further information is provided as it becomes available. invoia assists the Customer in meeting the Customer's obligations under Articles 33 and 34 of the Regulation and, taking into account the nature of the processing and the information available to invoia, Articles 32, 35 and 36. Notification to the competent supervisory authority and communication to the data subjects are carried out by the Customer.

9.12 Deletion and return. The Service contains no export function. invoia therefore cannot return the Customer's data in a structured, commonly used format as a function of the Service. The Customer is referred to the fact that the posted records already exist in the Customer's own Dinero organisation.

(a) Disconnecting the accounting connection. When an administrator disconnects the accounting connection, invoia's copy is deleted: customers, invoices, invoice lines, line assignments, work registrations, accrual vouchers, recurring series and credit notes are permanently deleted from the Service. The act is irreversible, takes place with no prior extraction and cannot be undone. The Customer must secure the records it needs before disconnecting.

(b) What is not deleted. Everything invoia has created in the Customer's own Dinero organisation — contacts, products, posted invoices, posted credit notes and posted accrual vouchers — remains in the Customer's own accounting system, where the Customer is the controller and where the Customer's own retention obligations, including under the Danish Bookkeeping Act, apply. invoia cannot delete it.

(c) Deletion of the whole account. There is no self-service function for deleting an account. Deletion is carried out manually by invoia on written request from an administrator on the account. invoia cannot commit to a deadline for completion and cannot guarantee deletion from the backups the hosting provider retains at its own intervals.

(d) Termination without a request. The Customer's data is not deleted automatically when the subscription is cancelled or ends. If the Customer wants deletion, the Customer must request it under (c).

(e) What invoia retains once deletion has been carried out. Once a deletion under (c) has been carried out, invoia continues to retain the information necessary to comply with a legal obligation, including accounting records relating to the subscription, where invoia is the controller. Until deletion is requested under (c) and carried out, the Customer's data is retained unchanged in the Service, see (d) and 14.3. There is no automatic deletion and no agreed retention period.

9.13 Documentation and audit. On written request, invoia makes available the information necessary to demonstrate compliance with the obligations in this section. The Service contains no customer-facing audit log, and invoia does not hold an audit report from an independent third party. If the Customer wants an inspection beyond written documentation, the timing, scope and method are agreed in advance. The inspection is carried out at the Customer's cost, under confidentiality, without access to other customers' data and without endangering the security or operation of the Service.

9.14 Precedence and duration. This section prevails over the other sections in the event of conflict concerning the processing of personal data. The section applies for as long as invoia processes personal data for the Customer.

10. Availability and support#

10.1 Basis of provision. The Service is provided as is and as available.

10.2 No availability commitment. invoia gives no uptime guarantee, no service level agreement and no compensation for downtime. There is nothing in the Service that measures or monitors availability, and there is no status page. Any statement of uptime would therefore be unsubstantiated, and none is given.

10.3 Maintenance and changes. invoia may carry out maintenance and may change, add and remove functionality. Maintenance and changes may cause interruptions without prior notice. If material functionality is permanently removed, notice is given under section 15.

10.4 Support. Support is provided by email at support@invoia.io. No response time has been agreed. Statements of usual response times elsewhere are indicative and not binding.

10.5 Third parties. invoia is not responsible for the availability of, changes in or faults in third-party services, including Dinero and the sub-processors listed in 9.8. If a third party changes or closes its interface, this may affect the Service without notice.

11. Liability#

11.1 Starting point. Each party is liable under the general rules of Danish law, subject to the limitations in this section.

11.2 Financial cap. invoia's total liability to the Customer is limited to the fees the Customer has paid for the Service in the 12 months immediately preceding the event giving rise to the claim. Several claims arising from the same circumstance or from interrelated circumstances are treated as one claim.

11.3 Indirect loss. invoia is not liable for indirect loss or consequential damage, including operating loss, loss of profit, loss of revenue, lost savings, loss of goodwill, loss of data, interest, or fines and other sanctions imposed by an authority, nor for the cost of additional bookkeeping or audit work.

11.4 Invoices issued in error. An invoice that has been posted and delivered cannot be withdrawn, and the only way to correct it is a credit note, see 6.3. Where an invoice is issued with incorrect content, at the wrong time or to the wrong recipient, the Customer bears the relationship with that recipient and with the Customer's own customers where the error is caused by

• the information the Customer has registered, including delivery details, see 6.4,
• the Customer's configuration or failure to switch off automatic issuance under 6.2,
• the Customer's failure to review under 6.7, or
• an act performed with the Customer's API key or access token, see 7.4.

In such cases the Customer shall indemnify invoia against claims brought by third parties as a result. Where the error is caused by invoia, invoia is liable subject to the limitations in 11.2 and 11.3.

11.5 Exceptions to the limitation. The limitations in 11.2 and 11.3 do not apply in cases of intent or gross negligence, in cases of personal injury, or otherwise where liability cannot be limited under mandatory law.

11.6 Notification of claims. Claims must be raised in writing without undue delay after the Customer became aware, or ought to have become aware, of the circumstance giving rise to the claim.

11.7 Force majeure. Neither party is liable for failure to perform caused by circumstances beyond that party's reasonable control.

12. Customer data and rights#

12.1 The Customer's data. The Customer owns its data. invoia acquires no ownership of it and uses it solely to provide and operate the Service and to comply with legal obligations.

12.2 No AI processing. invoia does not use the Customer's data to train models and does not disclose the Customer's data to providers of language models or other artificial intelligence as part of the Service. If the Customer itself connects an AI assistant under section 7, that disclosure is made at the Customer's own decision and at the Customer's risk.

12.3 invoia's rights. invoia and invoia's licensors hold all rights in the Service, including software, interfaces, design, documentation and trade marks. The Customer receives a non-exclusive, non-transferable right of use for the term of the agreement. Suggestions and improvement ideas the Customer sends to invoia may be used by invoia freely and without payment.

12.4 No export. The Service contains no export function. The Customer cannot itself extract its data in a structured format, and invoice documents cannot be downloaded from invoia; the documents are held in the Customer's Dinero organisation. The Customer should therefore ensure that the records it needs exist in its own accounting system.

12.5 Confidentiality. Each party keeps the other party's confidential information confidential and uses it solely to perform the agreement. The obligation applies also after the agreement ends.

12.6 References. invoia does not use the Customer's name or logo as a reference without the Customer's prior written consent.

13. Term and termination#

13.1 Term. The agreement runs from the creation of the account until it is brought to an end.

13.2 Termination by the Customer. The Customer may cancel the subscription under 5.6.

13.3 Termination by invoia. invoia may terminate the agreement on 30 days' notice to the end of a billing period.

13.4 Termination for breach. Either party may terminate the agreement with immediate effect on the other party's material breach that has not been remedied within 14 days of written demand. invoia may further bring the agreement to an end with immediate effect on non-payment after reminder, or where continued provision would be unlawful or would entail a material risk to the Service, to other customers or to third parties.

13.5 Suspension. invoia may suspend access instead of terminating where suspension is sufficient to address the matter.

14. Effects of termination#

14.1 Access. On termination the Customer's right of use lapses and access to the Service is restricted.

14.2 The automation does not stop by itself. The scheduled runs are tied to the connected accounting connection and not to the status of the subscription. If the subscription ends or is suspended without the accounting connection being disconnected, the runs may continue to post and have invoices delivered in the Customer's Dinero organisation. If the Customer wants the automation to stop, the Customer must disconnect the accounting connection, and the Customer should do so before the subscription ends. The Customer bears responsibility for doing so in good time. Note that disconnecting also deletes the Customer's data in the Service, see 9.12(a).

14.3 Data is not deleted automatically. The Customer's data in the Service is not deleted automatically on termination. Deletion takes place under 9.12.

14.4 What survives termination.

• Everything posted in the Customer's Dinero organisation remains in the Customer's own accounts. invoia cannot delete it.
• The billing record held with invoia's payment provider — company name, billing email address, billing address, VAT number and the invoice history for the subscription — remains, as it forms part of invoia's own accounting records, where invoia is the controller.

14.5 Payment. Fees due and accrued remain payable. No refund is made, see 5.7.

14.6 Surviving provisions. Sections 9, 11, 12 and 16-18, together with any provision which by its nature is intended to survive, continue to apply after the agreement ends.

15. Changes to these terms#

15.1 Right to change. invoia may change these terms.

15.2 Notice. Material changes and price changes are notified to the account's administrators at least 30 days before they take effect. Other changes, including corrections and clarifications, may be made by publication on this page.

15.3 No renewed acceptance. No renewed acceptance is obtained in the Service. Continued use after the changes take effect constitutes acceptance of the amended terms.

15.4 The Customer's choice. If the Customer does not wish to accept a material change, the Customer may cancel the subscription before the change takes effect. The subscription then ends at the end of the paid period, and no refund is made.

15.5 Current version. The version in force at any time is shown on this page with its version number and date.

16. Governing law and venue#

16.1 Governing law. The agreement is governed by Danish law. Danish conflict-of-law rules that would lead to the application of other law, and the UN Convention on Contracts for the International Sale of Goods (CISG), do not apply.

16.2 Negotiation. The parties shall first seek to resolve a dispute by negotiation.

16.3 Venue. If the dispute cannot be resolved, it shall be decided by the Danish courts, with Københavns Byret (the Copenhagen City Court) as the court of first instance.

17. Language#

These terms were drafted in Danish. The Danish version is the legally binding one. The English version is a translation made available for convenience only. In the event of any discrepancy between the two versions, the Danish version prevails.

18. Contact#

Creo Digital CVR no. DK45246132 Email: support@invoia.io

Notices under these terms are sent by email: to invoia at support@invoia.io, and to the Customer at the email addresses registered for the account's administrators.

See also Privacy Policy, Cookie Policy and Security.

Last updated: 15 September 2026 · Version: 2.2