E-Invoicing formats ZUGFeRD and X-Rechnung are now available
With E-Invoicing in Germany taking a step forward in 2025 we are happy to announce those new E-Invoicing formats being available using Nitrobox!
Under Global -> Config -> Document Provision in the webportal you can configure which format should be available in which situation (Note: This webportal config is currently only available for "Beta Preview" users, this flag will be removed in the following release). ZUGFeRD will be embedded in the pdf you know and love, while for an X-Rechnung an XML file is created as an attachment on the document. Those files can then be provided to your customers are usual.
Click here if you are interested in learning more about how Nitrobox can help you with your E-Invoicing needs.
New Dashboards
We've added a few additional dashboards to give our users a faster overview of potential issues.
1. Failed Billable Items
  Was there an Error when billing an item?
2. Failed Notifications
  Were all Notifications successfully sent to an integrated system?
3. Failed Payment Intents
  Were all payment intents successfully executed?
4. Unassigned Payments
  Any payments that couldn't be automatically assigned? If you configure this to be a table, you can quickly assign payments directly from the dashboard.
5. Uncategorized Payments
  Were any payments received where we couldn't assign a category? If you configure this to be a table, you can quickly categorize payments directly from the dashboard.
6. Failed Basware Workflows
  Were there any issues transferring e-invoices to Basware?
7. Overdue Documents
  How many of your issues documents are overdue?
8. Contracts expiring within (time)
  Any contracts that will soon expire?
Default Dashboard
To get users started with our Dashboard we now provide a couple of interesting widgets that should help our users gain an overview of potential issues requiring attention in our system. Here is what it looks like:
Operating site country in Tax Rules
If you run a cross-border business with different operating sites, then taxation is not just dependent on where the service was provided, but also from where it was provided. This can now be modeled using our Tax Rules by setting different rules depending on the operating site.
Location extension
We've extended our location objects from Line Items, Allowances, and Usages by street, postal code, city, and state. They can then be printed on your document pdfs if you want to emphasize the exact location where a service was provided (for example for e-charging stations). Down the line, those values can also be used for tax purposes if your tax jurisdiction requires taxation by exact location such as in the US.
Further Webportal enhancements
1. We added an ident quick search to our webportal header. Entering any search term will suggest Customers, Plans, Contracts, Orders, and Documents that contain the term in its ident. This will allow users to navigate through our system faster.
2. We extended the Order list view with aggregated agreed and actual deposit sums, and open deposits so you can more quickly see Orders where your customers have not yet paid their deposits.
PDF templating enhancement
1. Customer Payment Account information is available to be printed on your document pdfs.
Bugfixes
1. Resolved an issue where payment transactions displayed an incorrect status after a payment reversal followed by reassignment to another order.
2. Fixed a bug where self-billing address invoices could only be corrected once.
3. Fixed a bug where self-billing invoice address correction documents used the new address instead of the old.
4. Fixed a bug where canceling a contract nanoseconds after creation could lead to an invoice but no cancellation credit note being issued.
API Updates related to operation names
We have updated our APIs to resolve issues caused by non-unique operation names (referred to as "operationId" in our OAS specification files, available here). Previously, non-unique names led to ambiguous references in our API documentation, such as links like https://docs.nitrobox.io/reference/get_1, which were sequentially numbered but not guaranteed to be consistently over time.
These naming conflicts also impacted client-side code generation and resulting method names. We now provide unambiguous and self-descriptive operation names to address this for easier use and improved clarity.
Affected API versions
1. Payment API v2-1.68.0
2. Payment Assignment API v2-0.200.0