Try ERPNext Buy Support Partners Foundation

ERPNext and Quickbooks Online

What is the current status of integrating ERPNext with Quickbooks Online?

I’ve found a post on this site as well as github issues and a couple PRs but nothing is conclusive.

Below is what I’ve found so far and it leaves me wondering if this is something that’s just too difficult to implement or simply not a wanted feature.

  1. Quickbooks integration
  2. https://github.com/frappe/erpnext/issues/5202
  3. https://github.com/indictranstech/erpnext_quickbooks
  4. https://github.com/frappe/erpnext/issues/15304
  5. https://github.com/frappe/erpnext/pull/15308
  6. https://github.com/frappe/erpnext/pull/15718

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

After being restored, this is now a duplicate of Quickbooks Online integration

@jeffc We were a recent sponsor of some work on the QBO Migration Tool. As of ~18 months ago, it kind of worked but was pretty fragile. (And it is important to understand that this was only a one-way, one-time migration.). One way syncing is much harder and Two-way syncing is probably out of the question.

At the time, we had modest interest from a client but that never got to the point where all parties were motivated to get “into the gears” and make the tool robust enough for regular use.

Currently I am working with two clients who are both switching from QBO. But I doubt that either of them are going to be interested in “migrating” and will choose to just “cut-over” instead.

At some point we will probably revisit this, but not for at least 6 months. If we do take it up again, my inclination (and I am not very smart about these things!) is to start with an Account Mapping Tool so that QBO could push their histories into a standardized CoA. I am pretty sure that the most recent version needs to be run on a clean-install and it writes a QBO-style CoA.

Sorry we can’t be more help. It is a deceptively tricky problem.

@MichaelPinkowski

I’m not looking to replace QB or even use many of the accounting features of ERPNext.

My current thoughts are:

		QBO	ERPNext
Time Sheets	    <--
Customers	    <-->
Vendors		    <-->
Invoices	    <---
Employees	    <---
Class		    --->
Service Item	    --->

In essence, use ERP for time tracking and reporting time with projects but have the time exported to QB for payroll.
Customers synced so that we can report our projects and other ERPN items against.
Vendors and invoices to utilize the invoice approval work flows and then export the invoice with pdf attachment to QBO for payment.
Employees so we can use the employee onboarding and other HR modules. The employees will need to match what’s in QBO for timesheet/payroll purposes.
Class & Item because they are how things are tracked/organized in QB.

With QBO, I’d think that sending/receiving data would be pretty straight-forward usign python requests or the QBO API python module.
I can see potential issues with a bi-directional sync if you depended on having an accurate ledger on both sides. But if you really don’t care about the ledger of ERPNext are most of the sync issues mitigated?

What type of issues did you encounter with one-way syncing and why do you say that a bi-directional sync is probably out of the question?

First of all, I am not a good resource for this. (I wouldn’t trust me…!). And secondly, it has been a while since I have looked into any of this so my memory may be wrong or things might have changed.

BUT, my recollection is that ERPNext and QBO have very different approaches to items (and my suspicion is that it gets even harder with Service Items.). That means that I foresee issues around Invoices. (SO/SI/PR)

Having said that, it is probably do-able or at least exploring further. My recommendation is to expand on the idea that you have outlined above and post it to https://erpnext.org/erpnext-jobs

Again, sorry I can’t be more help.

I sometimes have prospects and customers ask about this. A while back, I did my own research. I discovered a similar set of links, which @jeffc already posted above. My conclusion was:

  1. Historically, some attempts were made at QB migration and integration.
  2. Nothing was ever completed and publicly released.
  3. It’s possible someone(s) have created private solutions. But if so, we don’t know about them.

I’ve done a ton of ERP data migrations and integrations in my time.
What @MichaelPinkowski mentioned, a one-time data migration tool, is quite challenging.
What @jeffc is looking for, a multi-use sync tool that runs on a schedule, is really challenging.

I’m confident this could be accomplished using the QBO API, the Frappe API, or some combination of both. It’s just a really big project.

  • Mapping various tables, fields, and data types. Sometimes this is obvious. Other times there is room for interpretation.
  • Handling cases were Side A has data elements that Side B does not. And vice versa.
  • Timing and scheduling.
  • Writing rules for handling data conflicts, and deciding who “wins” when there are disagreements.
  • Logging all the conversion work.
  • Creating dashboards for monitoring the integration.
  • Creating processes to fix the integration when it gets “stuck” or “broken”.
  • Creating “rollback” processes to fix the damage done, when the integration creates bad or garbage data.
  • Ensuring that Users don’t access data in the middle of a sync, and view “half-integrated” data on the browser.

Plus as Michael said, there could be some fundamental differences to resolve. Which may require actually modifying Frappe/ERPNext itself, to accommodate.

Still, all quite doable. It just requires time and funding. Some client(s) with a strong need for an industrial-strength integration. Who also have the budget to fund the development work.

So far, everyone I’ve personally spoken with felt such an integration was a “nice to have” feature. But weren’t willing to go all the way. Opting to either just continue using QuickBooks Online. Or deciding that using ERPNext exclusively was a better idea, since it has most of the same features as QB.

1 Like

Coming into this discussion a little late but I had missed this thread before. We are also curious about this since our company currently uses QBO and our accounting staff are experienced with it. The ERPNext support folks tell us that they can support a QBO<>ERPNext integration, but I haven’t gotten hard details on how that would work or what the level of effort is.

Is there any clear comparison of QBO vs ERPNext Accounting? Would be very helpful if there was a feature by feature comparison. QBO has a whole ecosystem of plugins and integrations which many companies rely on (including payroll etc), but the basics certainly are not rocket science. Accounting is also a mission critical system and most companies are not likely to want to take any risks with major problems.

I note there is “Quickbooks Migrator” which appears to have relevant commits in late 2019. Documentation for that module https://docs.erpnext.com/docs/user/manual/en/accounts/quickbooks-migrator exists but has some holes.

It can sometimes be challenging to find a person who:

  • Has deep knowledge of both products.
  • Who reads these forums, and noticed this thread.
  • Who feels like responding with a detailed, feature-by-feature comparison.

The easier approach is to identify the features you need, and create a list. Then ask someone to review your list, and reply how ERPNext compares.

The challenge here is that ERPNext and QBO are similar. Yet also fundamentally different.

QBO is a specialist. It’s great at what it does. Tracking invoices, payments, time, tax, and payroll. If that’s all you need? Excellent. You get that. But you must use the processes and workflow, exactly as offered. You must do things “the Quickbooks way”.

ERPNext is a generalist. It does those things too. But (in my opinion) in a general, unrefined way. It provides the basic necessities. It has a nice Accounting package that does the usual things.

However, ERPNext offers a lot more. Its design is known as a “monolith”. It automatically ships with CRM, Inventory, Manufacturing, Project Management, Quality Control, Human Resources, Point of Sale, Assets. And lots more. It is a “jack of all trades” software platform. And a very global/international product, with users on all 6 continents, and tons of language translations.

But also, ERPNext is open-source and fully customizable. Like QBO, you can modify reports and printouts. With no limits to your report’s design. You can also add new data tables. New screens. Entire new modules. You can see and edit every single line of code. Need ERPNext to integrate with Shopify? Amazon? Track the stock market? Communicate with a weather station in Antarctica? No problem. Just add the code. It’s ready for you to teach it new things.

QBO is solid and polished. If you like what Intuit offers? Or if you can purchase marketplace add-ons that work for you? Fantastic. But once you need it to do something new, different, or better? You’re out of luck. It’s not your software. It belongs to Intuit. You cannot improve on it. And you’ll pay the rates they tell you to pay.

ERPNext is like owning 30 boxes of Lego blocks. When you’re done following the instructions, you have 30 interesting things. But you’re free to modify them. Add more Lego blocks. Or attach them to a Raspberry Pi and make a robot.

If you don’t care about any of that? Then QBO may be better.

Hopefully my response explains why “cost of integration” is not a question with a quick answer. An integration could take a few weeks of effort. Or 6-12 months. That depends on what is required. And also your comfort-level and experience working on a joint-project with ERPNext consultants and developers.

2 Likes

Reasonable. Certainly I get the advantages of an OSS solution or I wouldn’t be poking around with ERPNext at all :slight_smile:

Accounting is particularly troublesome since I am not an accountant. My engineers are DEFINITELY not accountants. My accountants are DEFINITELY not software developers (or “computer whizzes” at all for that matter). It is mission critical but also at the hub of many of the efficiency improvements we would like to implement with ERPNext. So it takes a bit of poking for myself and other technical types to come up with an accurate list of what we need our accounting system to do. We will continue poking at it. I can familiarize a bit more with our QBO.

Appreciate the commentary!

I can definitely empathize. Everyone knows their jobs. But most likely, those jobs are not written down and documented. So that an engineer could open documents and know what accountants do each week. Or vice versa.

Documenting our jobs is not something we humans are normally good at. We spend time “doing”. Not writing step-by-step job instructions.

Yet until you know what your accountants and engineers need, you won’t know for sure if ERPNext can do it “out of the box.” Or the cost of bridging the gap.

Another thing you could try is playing with a demo. Or hire a consultant to give an online demo, and invite your accountants and engineers to attend. They can ask questions and get feedback. And you’ll all have a better idea of capabilities.

1 Like

In my experience rolling out ERPNext at a few different organizations I am associated with, a successful deployment (especially away from something like QBO) really needs an internal evangelist: somebody inside the company who spends the time to really learn the system inside and out, who can be available at a moment’s notice to explain how something works or why something isn’t working.

I completely agree with Brian’s comparison of the two platforms. Frappe/ERPNext is extremely rich as a metadata framework and API. Nothing else out there compares. Compared to QuickBooks, however, Frappe has very little workflow-specific UX. Sales invoices look and work pretty much the same as hospital admission records or manufacturing orders. That’s an advantage in many respects, but it also limits Frappe’s ability to really optimize a workflow to a specific use-case the way that QBO does.

As a path forward, I think there’s huge untapped potential in the custom Page doctype. Pages allow for pretty much any layout and workflow imaginable, with Frappe’s session management, permissions, api, and utility libraries (including Vue.js) ready to go immediately. The point-of-sales register is a great example of the kind of UX optimization that’s possible on top of Frappe’s document-based data framework. With a bit of customization, it would be very possible to use custom Pages to achieve the kind of user experience that QBO has built in, all while maintaining the flexibility of the Frappe framework.

Frappe has evolved in great ways over the last few versions especially to facilitate that kind of customization, but unfortunately customization always involves some amount of work. In this, the companies that struggle are the ones in the middle: those that have grown past the limits of QBO but who don’t have the scale to justify a lot of in-house customization. As Frappe gets easier and easier to customize from the front end, my hope would be that the platform can capture more and more of that middle space.

2 Likes

I agree completely on the potential of Pages. If the application can ship with some sample/default Pages (ex. purchasing, sales, a few inventory operations), that would lower the cost for those mid-size companies. Instead of hiring techno-consultants to build Pages from scratch, they’d only need someone to tweak and made adjustments to what is already in place.

Lately I’m spending far more time customizing screens for my clients, to make the processes flow smoothly, than I’m spending adding new features.

Your mention of clients having an evangelist really resonates with me. All my best client experiences have had one. It makes a tremendous difference in how much can be accomplished.

1 Like