Issues with Billing and the QuickBooks Online Integration

dyoder

I've used QuickBooks Online for my business since 2014 and have a lot of data there - including all my service definitions, rates, etc.

There are a few things that really bug me about Atera's integration with QBO and it effectively stops me from being able to use Atera's billing features because it makes billing so much more difficult than just doing it by hand.

Service Dates

When I export an invoice from Atera to QBO, the dates on the service line items are the date of the export, not the date of the beginning of the service period. Since I bill in arrears, I almost never generate invoices for periods before the next period begins. So when using Atera, all my generated invoices have dates for the wrong period, so I have to change each date on each line item by hand after it's been exported to QBO.

Invoice Destination

Each client of mine is setup in QBO as a client (obviously), and each client's billing contact details are there as well (again, obviously). When I export an invoice from Atera to QBO, Atera overrides the email address the invoice is sent to and will only send it to the primary contact in Atera. This is problematic because several of my companies use outside accounting firms or require invoices be sent to both an inside Controller and the outside firm. Since Atera is unable to leave the preconfigured email destination(s) alone, I have to modify this by hand after the invoice has been exported to QBO too. The inconvenience to this is that I have to keep a separate spreadsheet detailing where invoices need to go for each customer, even though QBO is already configured to do what I need it to - Atera just gets in the way.

Device Counts

This issue has a few parts to it.

• The number of devices for each service is really high. Is Atera including retired devices in the counts?
• When configuring the customer contract, I have a very limited set of items to count by. I have rates for different device types - like a monitored website vs. a network switch. Unfortunately I cannot count these properly, so this too must be done by hand for each client.
  
  
• I cannot count devices that are using services I offer. For instance, if a device has the ESET and Bitwarden installed, it should be billed according to it's corresponding rate I've configured in QBO. Right now, invoicing based on this kind of criteria is impossible with Atera. Once again, these counts need to be manually tallied and modified by hand in QBO after exporting from Atera.
• When an invoice is exported to QBO, the service descriptions that I have configured in QBO are not used at all. Atera just copies the service name into the service description box which makes the invoices less professional and lacks beneficial information that should be present. Once again, I have to do this by hand in QBO after the invoice is exported from Atera.

Tickets

Atera will not bill a customer for a ticket until that ticket is marked resolved. If I spend time on a ticket and it just so happens to cross periods, I do not get paid for that ticket until the end of the period it closes in. This means:

• I cannot use tickets to work on long running issues.
• I cannot use tickets as a form of project management (like scheduling and communicating with a group of users about the status of an app upgrade or deployment)
• My cilents will puke if the work from multiple tickets gets unexpectedly billed in the same period.

This just does not make any sense to me, but I'm not the only one that uses Atera nor is my use case the only one that exists, so if this fits with your style of billing I would really love to hear about it!

Hourly Billing

If I setup a contract at a client for hourly work and I need to invoice that customer before the billing period is over (for a variety of reasons that I'll skip here), I cannot bill for any time spent on the hourly contract. I discovered the hard way that I needed to create a new contract for "on-demand" hourly work, then go back through all tickets for that customer and switch the contract to use the on-demand version instead of the hourly version. Now I'm thinking I need to change the contract to only use the on-demand version, but I'm scared of any unexpected changes that might introduce.

In Short…

Billing had always been done by hand before I moved to Atera. When I moved I was hopeful that an integrated ticketing system, device counts, and integration with QBO would solve a lot (if not all) my issues with billing by hand. After using it though, I pretty much have to build every invoice by hand just like I did before, only now it requires more clicks 😔

nina

Hi @dyoder - I understand you've been in touch with our Product Team previously regarding billing and QB.

We will take your request under advisement; though nothing is planned for the near future, hopefully, we will have some improvements in the not-to-distant future!

kim

Hi @dyoder! Thank you for this post. I had been looking at maybe using QB and the integration with Atera, but I was not quite sure about it since I had issues with QB in the past. I currently use FreshBooks, but I was looking at maybe figuring out how to link the API together with it to do billable hours. I know within Freshbooks I can do billable hours, but having it link with the ticketing would be cool. I wonder if using a third party like Zapier would help with those extra click issues you are currently experiencing.

Sincerely,

Kim

dyoder

@kim The issue with Atera and QBO is that every line item needs to be manually edited. Atera gets almost every single part of the invoice wrong - the service dates / period, the device counts / item quantity, the service descriptions, and the invoice destination - all of these have to be manually adjusted after Atera exports the invoice to QBO.

The part that's frustrating is that Atera is already integrated with QBO and can pull information from there, so why it can't pull the invoice destination and service descriptions is beyond me. And Atera already provides for "retired" devices to be omitted from reports, buy why omit them from reports just to include them in the invoices? Atera already knows what period I'm billing for, so why does it choose to use dates from the wrong period when generating invoices? None of these would require new features to fix, it's literally just adjustments in logic.

Because of these issues, I wouldn't consider Atera "integrated" with QBO. Atera creates it's own inaccurate invoice then sends it directly over to QBO without using logic or data available in QBO.

QBO, on the other hand, is great. I've been using them for a long time and am very happy with their service. I just can't use Atera's QBO integration to bill for more than a single customer right now. It's not worth the headache.

kim

@dyoder Thank you for the insight. I wonder if we were able to see the API coding in the community and then think-tank the corrections. This way we might be able to get this fixed faster since more eyes would be better than just one. I bet its just a few minor syntax changes then it would work as we want. I know it might be a heavier lift on our end, but I also would like to know how those integrations work so we can plan ahead for future feature sets. I don't see Quickbooks going anywhere anytime soon, so it would be advantageous if we could get that piece working for sure.

dyoder

@kim I fully support those in the community to take that on. However, I personally have no interest in providing free development time for Atera. If there was a compelling reason for me to remain with Atera, then yes - but as it stands now that isn't the case.

kim

@dyoder I can understand that. I'm a learner type and sometimes I just want to know how it works because it tends to help me out in other avenues down the road.

jon

@dyoder This post here is the exact reason I'm looking to leave Atera (at least for the PSA side). I just saw another similarly priced PSA/RMM tool that not only has QBO integrated but it also has 2 way sync. So get this; for the same price I pay for Atera I can use another software that actually exports the invoices properly without me having to spend close to 5 hours a month manually rebuilding every invoice, it also syncs back into the tool when an invoice is marked as paid in QBO!! This will take billing from ~5 hours a month to literally minutes. That is 5 hours of my life I will get back!

I literally came to the community this morning to see if QBO 2 way sync was on the roadmap and saw your post then I saw @nina reply that nothing is planned for the near future and that sealed the deal for me. Atera isn't going to offer the development needed on the PSA side for me to stick around any further. I've been with Atera for 4 years and as my business has grown it feels like Atera has been the biggest obstacle I face on a daily basis. Literally almost every other PSA tool offers what we're looking for as well as payment portals. Atera seems to only focus on RMM development.

I'm entirely dejected by reading the reply from @nina and now truly feel that I NEED to move on because the basics that I need for my business aren't there. I felt that the roadmap for Atera was amazing when I first signed up. I loved the platform when I only had ~50 endpoints and very few clients but now that I'm expanding and adding staff I truly don't feel that the PSA side of Atera scales well at all (especially with the billing issues you've highlighted).

Zeleration

I am really disappointed that Atera does not consider a working integration with QuickBooks Online (QBO) as a critical priority. At the very least, the integration should be able to create a bi-directional update between the web service and QBO, using the published API. It should also be able to generate a simple invoice with details such as tickets, time spent, and a link back to Atera if clients wish to see the ticket details. The main goal of using efficient MSP tools is to help grow our businesses. If generating invoices in QBO takes days of work, then it defeats the purpose of using the tool. Atera should not advertise that it has this feature if it does not meet the minimum viable product (MVP) criteria. This issue needs to be escalated.