Insights & updates from our experts
With the recent enhancement that makes it possible to relate effort classes to service offerings, a large step was taken in enabling MSPs to invoice the services they provide to their customers using Xurrent data. It allows work effort, recorded in time entries, to be related to a contract with their customer: the service level agreement. A next large step has now been taken, by enabling organizations to relate billable events in Xurrent directly to their invoicing tool, using billing identifiers.
Billable events in Xurrent can mean several things for a Managed Service Provider. Apart from time entries related to effort classes, which are used when a contract is based on time and materials, a service provider can invoice their customers per activity (fixed price). This is usually the case for standard service requests. RFCs, RFIs and incidents can either be invoiced as fixed price or time and materials. There is commonly also a monthly charge for the contract itself.
To be able to relate all these possible events to the external invoicing tool of the MSP, a ‘Financial Details’ section has been added to the service level agreement form, which is maintained by a person with the Financial Manager role of the account of the SLA.

As made clear in the example above, each SLA can have one Billing ID, which relates the SLA to a contract in the external system. For each effort class that is defined in the related service offering, a Charge ID can be entered in the SLA. If in that service offering one or more standard service requests are related, then these are listed under ‘Activities’. Activity IDs can also be entered for incidents with any of the impact levels (Top, High, Medium, Low), RFCs and RFIs. To add all these identifiers to Xurrent, MSPs with large numbers of customers and contracts may want to use the import/export functionality for SLAs, which has been updated to include the ‘Financial Details’ section.
The billing identifiers are visible on time entries associated with a billable SLA. In the example below, an RFI was registered in WDC and resolved by GlobalNet, who have the ‘Financial Details’ section as shown above defined on the SLA ‘Standard (2 Mbps) WAN Connectivity for Widget Europe (Amsterdam)’.

As the request of this time entry was a request for information, the Activity ID selected by Xurrent was the one defined for RFIs in the SLA. In case a request is both an RFC and a standard service request, the Activity ID for the standard service request is selected. Time entries on tasks and workflows that are related to a request which, in turn, is related to a billable SLA, also contain the billing identifiers.
To enable MSPs to use the billing data and identifiers from Xurrent, the Billing IDs, Charge IDs and Activity IDs are now also included in the export of time entries. They are retrieved dynamically from the respective SLAs. Only when a timesheet for a specific month is locked are the identifiers written to the time entries. This is important, as MSPs usually create a pro-forma invoice that needs to be verified and possibly adjusted. After locking the timesheet, it is then possible to update identifiers on the SLA, if necessary. This way of working ensures that the correct IDs are included in the export of the time entries, even if these IDs are modified during the life of the contract (of the SLA).
Whether the customer is invoiced based on time and materials or fixed price for work done on a request should still be defined and taken care of in the external invoicing tool, for now. In the next iteration of the Xurrent Billing Integration feature it will be made possible to define the billing method and the charges on the service offering record.

A Note From the Road: What SPARK Taught Me About Time
During the second SPARK event in Antwerp, I stood at the back of a training room and watched a customer build a custom integration with our new iPaaS, wiring Xurrent to another system in her stack that had never talked to it before. No services rep doing it for her. No statement of work, no project plan with a kickoff and a go-live date. Just a person with live beta access in her hands, connecting two systems by hand, and finishing it before her coffee went cold. A year ago that would have been a multi-week project with a budget attached. She looked up, a little surprised it had actually worked, and said something I have not stopped thinking about since. She said it just gave her her week back.

How Long Should ITSM Implementation Really Take in 2026?
Most vendors will tell you ITSM implementation takes six months to a year — but modern, configuration-first platforms have rewritten the math entirely. See what real implementations look like in 2026, and why a long rollout is now a choice, not a given.






.webp)





.webp)
.webp)














