Wouldn’t Kanhaiya Kale from Inductrans have what you are looking for? Shouldn’t Inductrans be part of the discussion, since they have already done most of that work? Aren’t they part of the community?
Here are messages from people who have tried this:
https://discuss.frappe.io/search?q=quickbooks%20connector
Fundamentally there will need to be some active leadership from someone/anyone in the community if we want to see a QBO connector. And as of now, it doesn’t look like anyone wants to take that responsibility.
Until that changes, the status quo will continue. That’s just the simple fact of the situation.
What do you need to do on ERPNext thatyou can not on quickbooks ?
@adam26d - it is actually the other way around. Its what you can do on quick books that you cannot do on ERPNext. Lots of good discussion and certainly lots of ways to “solve” for this challenge.
The biggest challenge with an integration of some kind to any accounting platform (QBO or any other one) besides the technical challenge is the process challenge. Different companies have different needs and the various processes that each company uses to operate are probably going to be somewhat different. Each company will have to determine where the demarcation point will be between what is kept in ERPNext and what is done in external accounting package/integration.
One of the things that annoys folks that use the big ERP platforms (SAP, Oracle Financials, PeopleSoft) is those platforms force you to work “thier” way. One of the great things about ERPNext and OSS in general is that they are more fluid and allow for different operating environments. This is one area where ERPNext does well. However with more fluidity, comes more complexity. More settings to tweak.
I am neither all “for” or “against” a connector. I do agree with @fblauer that the amount of features in quick books is massive in comparison to ERPNext and so if the foundation team is interested in keeping it all in ERPNext then that will require a great deal of development time and effort. Hence the call for the connector (thinking that would be easier).
I will continue to be an active member of the community and will continue to advocate for features and improvements in the platform. However they are developed are up to different set of folks.
This last comment is going to be off topic – If the foundation and ERPNext team really want to improve how things operate in the tool they really need to look at the interface. Multi-page dialog boxes are a pain point. Tons and tons of clicks just to get stuff done is a pain point. This is not just in accounting, its fundamental. Just my two-cents.
I have been using ERPNext for two years now and my CA (Accountant) is still not comfortable with the accounting module yet so I can relate to the discussion here. The trust she has with Tally is just not there yet with ERPNext. For the next year our company is running both systems to cross-check the reports.
We can contribute my CAs time towards any help required as well as some development time from a company developer (a newbie not an expert).
However, to use the time wisely we would need clear specs and tasks of what needs to be done.
“What do you need to do on ERPNext that you can not on quickbooks”
See this thread, above for a partial list.
As discussed previously in this thread, this has already been done. A connector exists which is about 80% complete. Why not complete it rather than starting over again?
Also, there seems to be political roadblocks:
Why do a lot of work if its not going to be a part of the strategy, maintained with updates, bug fixes etc?
Here is a recent article (yesterday) which talks about the same strategy. In this case, it is Xero which is the hub of the “hub and spoke” model, since they dominate in australia. The same concept applies to QBO in north america. Would be even better if we could support more than 1 accounting service hub :
Here is another example of what I am referring to:
Seems to me that we would need about 50 more code sprints to get all the features that the other accounting services already have. Or we could have 1 code sprint to finish the accounting integration, which is about 80% there. That’s the way I see it.
The most important thing for accounting entries is the account itself. Erpnext has as a base the account name and not the account code . These are two different things. In Greece and in most European countries the account code is the one used for every account entry and account print. Next thing would be to design the different accounting printings for each country. We may have a long way but I thing Erpnext can be an erp for every need if we all work together.
This is an important feature in any Erp software, integrated with another/external accounting software or not.
This is a classic “best of breed” vs “integrated” discussion. Strategically, you’re right in that ERPNext goes for integrated rather encouraging best of breed. Whether that’s the right strategy is a different story, which I realize is what you’re getting at 
This is an interesting question. There have been multiple statements that once contributed, features would be taken care of by the foundation or core team. However, I’m quite skeptical of the sustainability of that when considering integrations though, especially with some of the complex integrations that this could potentially encompass. I am of the opinion that integrations should be introduced and maintained by service providers.
Regarding a quickbooks integration, there was only about $700 raised from the community (outside Frappe and the developers). Based on that particular metric, there doesn’t seem to be a lot of interest. I realize the fallacy of relying on the absence of anything to draw a conclusion, so this isn’t a conclusion in any way…just a statement on the current measurable metrics.
My personal opinion is a QBO connector is right up the alley of a potential North American chapter. Assuming things take off, it should be possible to get the resources together needed to complete the integration.
Apparently, its alive:
I agree. Keep it open source let the community build it internally
Might be a bit late chiming into this.
I think ERPNext in 2020 is OK.
Could be better, less clicks to do the actual accounting.
However, I prefer not to use QBO because of the sky high pricing, pricing squeeze.
I think ERPNext’s accounting could be suitable for small business.
And I 100% agree that accounting is part of an ERP solution
There was mention above, ERPNext use of account name instead of account code (account number) as the data key that identifies accounting records - account number is s mere decoration. In my experience, this could cause serious trouble for accounting of companies that have long account names that have the same characters up to the 120th character. The company might assume that since it uses account numbers, the chart of accounts uses account numbers as identifying key. In fact in code, ERPNext uses the long account name. So if the firm uses account names which differentiate only beyond the 120th character, it may select the wrong account and give erroneous results. I think ERPNext would be much faster and more powerful if it implements the short account number as the identifying key.
As owner of an SMB firm in the US, I wanted to make just a couple comments about ERPNext vs. Quickbooks Online (QBO): we use QBO for our daily accounting, and there a few features that are critical for ease-of-use which ERPNext does not currently duplicate:
#1 could probably be handled the easiest in ERPNext, with the most time-consuming part being the setup of payroll data exports and imports.
#2 would likely require an API to a sales tax computation service (with I’m sure has its own subscription fee).
#3 seems to be the most problematic missing feature of ERPNext. Since we deal with thousands of bank, credit card and PayPal transactions a month with around 10 different accounts & banks, if we didn’t have the automated feeds with easy online reconciliation that QBO offers, it would take dozens or more hours every month to enter and reconcile bank transactions in ERPNext.
Intuit (which makes QBO) has the resources to integrate with the hundreds of credit card companies and banks and their ever-changing security requirements and APIs. Odoo is also able to do it somewhat, to a lesser degree, using a 3rd party service, while ERPNext does not. I don’t expect ERPNext to offer similar online bank integrations any time soon.
For SMBs in the US, I think these ease-of-use features are more important than whether their accounting package is fully integrated with other ERP functions, or whether the accounting software is open source. Event at QBO’s price $40-150/month, it is still much cheaper than paying for many hours of bank entry and reconciliation if that work all had to be done manually.
For that reason, I think a good ERPNext-to-QBO integration would important for ERPNext to make inroads into the North American marketplace.
@BTN, I don’t have perfect info, but let me share some of my thoughts…
With those integrations in place, I think the question becomes, how can SMBs learn to step up to robust double-entry accounting (and all of the benefits of full-blown ERP)?
Sidenote: We supported development of the one-way QBO → ERPNext project and that is a fragile process. It is my impression that it is even harder to go ERPNext → QBO because of differences in the fundamental philosophies of the two systems.
Ironically, QBO doesn’t even satisfy our accounting needs; we’ve been using QB Desktop and Enterprise for years now.
I might publish our code for both the ERPNext-QB Frappe app with a qbXML tool. We wouldn’t be able to maintain or expand it much, as we only need a couple of niche things imported into QB.
Edit: the idea is to be able to translate invoices with ERPNext customers/accounts into qbXML to import into existing QB accounts.
Maybe the existence of FrappeBook will close the gap and solve the dilemma of integration or enhance the accounting module of ERPNext