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