We've enabled our new rights and roles system that will allow you to provide better matching roles to our users than ever before. You can view the new roles when creating new users or managing existing ones, where you will also find more information on what each role contains.
Existing users retain their current rights, but we recommend you migrate your users to the new roles. We plan to remove the old roles within a year, so Users not migrated in that time might lose access.
Billing Group and Business Segment are now available for considering during deposit created booking rules, allowing for more specialized bookings.
Fixed a bug where during Plan creation you couldn't switch between billing timing with delay and without.
Fixed a bug where Contracts couldn't be created for Plans with quarterly billing and autorenewal.
We've enabled a new feature that validates the VAT-ID of your B2B customers. This can be necessary if you engage in cross-border business and use the reverse-charge system. As reverse-charge is only valid for business customers that are VAT registered in their own country, their VAT-ID being valid is very important and now our system can ensure this validity.
If you want this feature enabled on our tenant please speak to your professional services contact.
When enabled, you can see the result of the VAT-ID validation in our webportal.
We also archive the validation result with our certified archiving provider together with each document created.
You can now configure our payment matching rules to also automatically assign matching underpayments. While this increases the share of payments that will be automatically assigned, it also slightly raises the risk of wrong assignments. It can be very helpful for certain setup scenarios, so we invite you to evaluate this feature for your use case. Feel free to reach out to our support team to help you decide if you should enable this feature or not.
Using our webportal, you can now update the payment terms of Orders and Contracts in case you have renegotiated those with our customer.
This is helpful for integrations that provide entire documents to our system instead of interacting with our Orders and Contracts. This can be the case if you generate for example invoices (with or without the pdfs) in your system and need to generate invoice numbers in your system, but are still looking to use our products' payment and accounts receivable management capabilities.
Note: You can define for each billing group if you want to handle the billing externally (using the document API) or internally (using our Orders and Contracts). See more in our documentation about Billing Groups: https://docs.nitrobox.io/docs/billing-groups
You can now open Booking Periods manually. While they are created automatically as well when a new financial transaction takes place in a new Booking Period, especially when setting up a new tenant creating a BookingPeriod manually to define an accounting baseline can be helpful.
Fixed a bug where in the webportal, filtering with equals sometimes returned wrong results.
We've adapted the billing behavior of line items added during contract creation. For contracts billed at interval start, line Items provided during contract creation will now be billed with the first invoice. Any Line Item added later will still be billed with the following invoice. This behavior change allows you to invoice your customer's Line Items even earlier without producing additional documents.
If you are using our API to close OPOS cases, you don't have to send the amount anymore. If left empty, the amount will be automatically the leftover amount of the OPOS case. This should make any integration a lot easier if you are just looking to close the opos case to prevent for example dunning.
Dunning can now be set up in a way that doesn't create any dunning letters on our end. This can be helpful if you already have a dunning letter creation functionality in our ERP for example. In this case, you can just listen to dunning status changes from us and then create and distribute the dunning letters yourself.
Contracts can now receive Usage Add-ons. So if you have new Usage based products you can enable them on existing contracts as well. Previously this would've required a new contract.
Fixed a bug where multiple contract-expired events were sent out when the contract was updated after it expired.
Our reports have been extended to also contain an ident. This makes it easier to know which reports you have already fetched.
To have a better overview of the health status per contract, the dunning status of a contract can now be requested via our API (soon also available via our Webportal). You can also be informed via notification if this status changes, named "Dunning status aggregation updated".
Fixed a bug where manual opos clearing during payment assignment sometimes did not work.
We are extending all of our already deprecated API endpoints with the information specified in our policy, one example can be viewed for Purchase Items here. Note: The sunsetting date for this specific endpoint is in the past already which is an exceptional case. The purchase item endpoints were officially deprecated over a year ago (see our migration guide), but it wasn't as transparent in our API documentation as we wished. While updating our policy and making this much more visible in our API documentation, we want to finally ensure this endpoint is not used anymore before actually removing it. For new deprecations, such care will not be taken and deprecated endpoints will be available until the sunset date communicated at most.
Contract locations can now be updated with our webportal. This comes in handy when a customer moves to a different country and should thus be billed different amounts or be taxed differently.
A new notification has been added: "Report created". You can subscribe to this event with your application and fetch the report immediately.
Fixed a bug where assigning a debit transaction was not possible.
Document number ranges can be configured in our Webportal. This means easier setup for new tenants and new number ranges, without support from our NBX professional service colleagues.
Rated Usages are now shown under contracts and documents, allowing for better transparency in how they are being billed.
We've added the ability to extend your custom reports by our properties as well, increasing the amount of data provided to you.
We have extended our document aggregation strategies to allow for more flexibility. You can now for example sum up multiple different item groups into one custom subtotal. Those custom subtotals and our previous sub totals are also displayed on the invoice detail page.
Fixed a bug where new payment assignments weren't shown on payment transactions.
Fixed a bug where customers couldn't be billed if they reached over 5.000 addresses.
Added a feature to delay the charging of payments until the invoice's due date. Potentially created partial credits are taken into account, charging only the actual open amount at the time of due date arrival.
Payment transactions are now assigned directly to a document before a settlement is posted. A PreBooked Item is created in the Opos overview to provide better payment insight.
You can now turn off the creation of "zero-amount documents" in your Billing Groups. This allows for better integration with legacy general ledger systems that can't handle such documents. This option can be enabled within the Billing Groups settings.
In our Webportal the account name for any GL account is now displayed next to the account number on all bookings, so you no longer have to remember all of your accounts.
Payment Terms for Contracts and Orders can now be updated via API, in case you come to a different payment term agreement with your customers.
We enabled the first part of our rated usage feature in our Webportal. While already completely available via API, you can now use our Webportal to configure Rated Usage Options and attach them to Plans. Those Rated Usages will become more visible in the coming weeks and months!
Fixed a bug in our Webportal, where the billable items processing date was displayed in the users local time instead of UTC despite being labeled as UTC.
