QuickBooks

Connecting Data Between QuickBooks and Other Applications–My Nightmare

Written by Doug Sleeter

Last summer I experienced a “data nightmare” with a QuickBooks data file. We were using QuickBooks Enterprise 12 R8 and the data file had about 5 years of transactions. The problems we encountered get to the core of what can go wrong when connecting two software systems together, but this case is specific to QuickBooks for Windows and connected add-on products that sync data with QuickBooks.

When it comes to connecting multiple applications together, either using desktop SDKs or cloud-based sync tools such as Intuit’s Sync Manager, there is quite a bit that goes on behind the scenes. While many of the behind-the-scenes functionality should be hidden from users, those who evaluate, set up, configure, and troubleshoot software systems will find great value in understanding the plumbing of each connection between “chunks” in these systems.

The short story is that we had a list corruption problem. We think it was caused by some combination of a bug in a QuickBooks add-on (which uses the QuickBooks SDK) and possibly the QuickBooks SDK itself. However, there is no way to know exactly how the file got corrupted. Trying to recover our data led to a cascading series of problems that I’d like to describe so that you can be prepared for a similar situation.

The Long Story…

We regularly import sales receipts into our QuickBooks file using a custom-developed data import tool (it uses the QuickBooks SDK). This had been working fine, but then we noticed that with recent imports the sales receipts showed the proper customer name in the “name” field, but they had the address for a different customer.

If we deleted those transactions and re-imported them, watching the exchange of information between the custom program and QuickBooks, we could see that the information being sent to QuickBooks was using the correct customer name. The address should be populated based on the customer name, but we were clearly seeing DIFFERENT customer addresses in the sales receipts than were stored in the customer record.

Whenever I see things like this, I immediately think the data file is corrupted. I have a list of steps to take to correct a corrupted data file:

  • First run the Verify Data function, and then the Rebuild Data function.
  • Resort the Lists.
  • Do a round-trip to a Portable company file (that is, save as a Portable company file and then restore from that).

Even after performing each of these steps, the problem persisted. So I started to panic…

Do we have a backup? Of course, but how far back would we need to go?  Before we went to the extreme step of restoring from a backup, we sent the file to the master of data file corruption, Matt Clark of QB or not QB.

Matt has several tools that allow him to fix, convert, delete, clean up, and reset transactions inside a QuickBooks file.  With our fingers crossed, we sent the file to Matt.

Alas, the file was broken in a way Matt had “never seen before.” As a simple test he tried an IIF import of a customer list, and that blew the file up. This was a good indication that the file was irretrievably broken.

Back to plan B (actually the last resort!) of restoring from the backup. The problem is, we had to go back 6 months, because each of our more recent backups were also similarly corrupted!

OK, so we should be able to use Karl Irvin’s Data Transfer Utility, which can read selected transactions from one file (our corrupted file) and add them to the restored backup. Although that seemed to work perfectly, (thanks to Nancy Gomez for helping us get that done) there are several near-game-over problems we found when we finished.

After restoring the backup and transferring over the transactions to bring the file up to date, all list items and transactions that are transferred will have NEW INTERNAL IDs! Records in QuickBooks have a unique ID that you don’t normally see in the user interface. This is why you can have duplicate invoice numbers, and can easily change the visible ID for any list or transaction record. The “real” identifier is this internal ID. When you use a transfer tool like the Data Transfer Utility, each record is assigned a new unique internal ID.

Why should that matter? Because the critical link between QuickBooks add-on programs and QuickBooks data relies on these IDs.

Since our process changed all of the internal IDs for the transferred records, all of our add-on programs can no can no longer connect THEIR data with the matching data in the updated/recovered QuickBooks file. These add-on products (either SDK or IPP based) need to have a unique reference to each QuickBooks record, so they will store the list and transaction IDs in order to access them. When we transferred the records from the corrupted file to the older backup this changed the internal ID’s, so the other add-on products that we use can no longer find their mommies. And these are children, so when they cannot find their mommies, it’s very sad.

Here is why it’s so bad:

  • Our CRM program (which connects to QuickBooks) can no longer find the customer names, so on the next sync it will assume it has to add new names to the QuickBooks database (or get new names from QuickBooks), thereby creating duplicates. Big problem!
  • Bills and payments in Bill.com cannot find their matching transactions in QuickBooks, so they must create new ones (again, duplicates!).
  • Documents stored in SmartVault are no longer listed in the folder displayed on the toolbar for that data set.

Note that for some QuickBooks add-on programs creating a new file in this manner is not a problem. QQube and other read-only add-ons generally won’t have a problem and they will resync just fine. The general rule is that any program that stores data outside of QuickBooks, and associates this data with the data in QuickBooks, will probably have a sync issue when you reconnect after restoring or removing data.

So, What To Do?

The only way to “Fix” this problem is to do some type of “resync” of the data in the back-end of the add-on software. This isn’t simple.

First, you’ll need a table with three columns (Record Type, Old ID, New ID) for each record that was transferred in by the Data Transfer Utility. I call this my “resync table.” Luckily, Karl Irvin was able to provide us with this as a special favor, but you could create it yourself by connecting to QuickBooks from Excel using the ODBC connection (which comes with Enterprise, or you can purchase it from QODBC.  You can also use one of several reporting tools available to extract the IDs from transactions and lists.

Of course resyncing the data in all of your QuickBooks add-on programs cannot be done by normal humans, if at all. Most likely you’ll need the help from the add-on developers. In our case, Bill.com was nice enough to do a re-sync for us after we provided them with the resync table. But for the developer to do this, they might have to write a special script to reach into their databases and update the IDs as prescribed in the resync table.  The big point here is that this asking a LOT of the add-on developers. Especially when the original “corruption” problem was in QuickBooks, not their database.

The Lessons To Be Learned

Here are some tips that will help minimize the chance that you will run into problems like this:

  • If you suspect any problem with the connection between and add-on and QuickBooks (for example, if QuickBooks quits with an “unrecoverable error” followed by a message to restart the program) you should immediately stop and check for corruption and correct the problem. We saw an error message somewhere during our imports, but nothing seemed wrong so we continued working with this data. That may have been our fatal mistake.
  • Another important step is to implement a good backup system that lets you archive your data, rather than just writing over the one backup you have. We minimized our problem by being able to go back in time to a backup copy that did not have the corruption problem.
  • Periodically check your backup system by doing a test restore to be sure that the backups are valid.
  • Make regular backups using the internal QuickBooks backup feature, as that does some “house cleaning” in your data file (make sure you have the “verify” option turned on).  Periodically perform a Rebuild, and do before/after comparisons of your financial statements to see if there are changes. Clean up any errors you find before they build up and corrupt your file.

So be forewarned. If your QuickBooks file is connected to other apps that sync with lists or transactions, and you plan to do any of the following, you should carefully consider the issues in this article:

  • New setup of a QuickBooks file for the same company, using existing QuickBooks data.
  • Remove customers, vendors, items, or transactions from QB file using the QB condense function, or any other utility.
  • Restore a backup and then re-enter data that was once in a newer version of that same file.

QuickBooks can’t provide ALL of the features that a business needs, so we have to rely on QuickBooks add-on products. The products that we use are high quality products, but the inherent nature of a bi-directional sync with QuickBooks and outside data means that we have to manage our files carefully.

I welcome your comments and experiences. Please share them here and we’ll do our best to help you through the forest. We’re still in the wild, wild west, so these are the types of issues that developers and platforms must perfect in the future. Developers, I hope you’re listening. This IS the issue when it comes to integration with QuickBooks.

About the author

Doug Sleeter

DougSleeter (@dougsleeter) is the founder and former CEO of The Sleeter Group, an international network of accounting software consultants, and the former producer of SleeterCon, an annual conference and tradeshow for accounting professionals.

In 2015, he sold The Sleeter Group to Diversified Communications (www.divcom.com) and the company has since become The Accountex Network.

He is a passionate leader of innovation and change in the small business accounting technology world. As a CPA firm veteran and former Apple Computer Evangelist, he melded his two great passions (accounting and technology) to guide developers in the innovation of new products and to educate and lead accounting professionals who serve small businesses.

Always in search of the next big thing, he is currently focusing on digital currencies and blockchain technology. He believes these technologies will change virtually everything in global commerce.

The CPA Practice Advisor recognized Doug as one of the "Top 25 Thought Leaders" in the accounting profession and he has been named to Accounting Today's "Top 100 Most Influential People in Accounting" each year 2008 through 2015. In 2013, he was recognized by Small Business Trends with the Small Business Influence Champion award.

In the early 1990s, Doug was a pioneer in developing the first QuickBooks seminars in the country and has since built the largest group of accounting software consultants in the small business accounting profession. Doug serves on several advisory boards for technology companies and has consulted with numerous industry leaders including Intuit, Sage, Apple, and Adobe Systems. 

Doug is the author of numerous books and courseware materials including The QuickBooks Consultant’s Reference Guide, and QuickBooks Complete, a college textbook.
 
Doug attended both the University of California Santa Cruz and Santa Clara University and holds a Bachelor of Arts degree in Computer Information Systems. Doug and his family live in Pleasanton, CA. Doug's hobbies include woodworking, golf, and lifelong learning.

25 Comments

    • Keith, doing a “backup” using the QB backup feature, with full verification on, is something you should be doing regularly. This will take care of some issues that can build up (and if it won’t “verify” then you need to resolve the problems). Doing a regular “rebuild” is something that some people recommend – I’m not sure if it is always of value in ALL situations. Might not hurt. Round tripping with a portable file isn’t something I personally would recommend as a regular thing, I generally only do that if there are some problems that indicate this as being worthwhile. None of these procedures will hurt the integration with a third party product, as none of them change the internal ID’s.

    • Keith,

      Charlie already responded, but the regular verify is a great idea. The rebuild is something I do only when I see corruption.

      The round trip to a portable file (QBM) is also a good troubleshooting step for corrupted files. That has the benefit of rebuilding all the indexes in the file so it should a) fix corruption in some cases, b) reduce the file size and c) theoretically enhance performance.

  • The answer is simply don’t use mass data update techniques that rely on synchronization processes otherwise known as automated import/export)processes, in integrating add-ons with QuickBooks. I’m understanding that at some times you may need to have a bulk export to QuickBooks but it does represent a risk. However you can prepare for those one-time infrequent processes, doing so by having a proven recoverable back-up of QuickBooks prior to commencing.
    Software development best practice is to leave data where it natively resides. The traditional ways of integration where large amounts of data are moved between applications i.e. export/import in bulk presents a business risk is unsustainable and it is process intensive with no scalability. If the sync breaks part way through then how do you recover? Secondly moved data is immediately out of date, it ages and is only as good as the time since the last sync. Obviously the biggest risk from an accounting perspective is moving data TO QuickBooks.
    If an application connects live to the QuickBooks data file and reads the data in situ there is no chance of corruption. Updating data from the add-on, for instance creating an invoice in CRM direct into QuickBooks, only has the possibility of corrupting that one entry. However synchronizing all the changes say in the past day into QuickBooks is a business risk.
    As developers when we designed a link from QuickBooks to ACT! CRM we built it to connect live to the data file and make incremental live changes in QuickBooks and not drag great volumes of data between the two applications. In short, synchronization is old school and is not the way of the future, well designed APIs eliminate the need to.

    • Graeme, as you know, QuickBooks add-on developers have two relatively reliable methods of integrating with QuickBooks, the IPP and SDK interfaces. With the SDK (which you use, I believe), the main data resides in the QB company file, no synching is necessary. However, that ties you to a slow method of getting the data. With IPP, we don’t have any choice, Intuit is synching the data with their Cloud storage, where we access it. While we can say “don’t use IPP”, that isn’t a good answer moving forward, as Intuit is emphasizing the IPP interface (and there are situations where the only option is to use IPP, such as working with the international versions of QBO).

      Avoiding synching won’t resolve all of the issues raised here. First of all, corruption CAN occur in many ways. We’ll probably never know what actually happened with Doug’s company file, but it became corrupted, and it wasn’t likely that it was due to a “synch” operation. It isn’t clear if an add-on actually created the corruption, or if it happened due to some bug in QB and the add-on just exacerbated the situation by building on bad data. But, synching wasn’t the issue.

      Even if you are not synching, if you have any outside data to coordinate with QB, you run into the issue Doug raises. Lots of data cannot be stored in the QB data file itself – as you know, it is not an expandable database. So in your system, you have CRM data (or, ACT has CRM data) that isn’t stored in the QB database. You refer to the QB data in some way if you want to associate your data record with their data record. So if you want to link your data to an invoice in QB, what key value do you use? Do you use the invoice reference, “123”? No, you shouldn’t, because QB allows you to have multiple invoices with the same reference, AND the user can easily change the reference. You use the internal ID. That is the key here – your software links your CRM record with the internal ID in QB – but then if for some reason you have a catastrophe, and you can’t rebuild the QB data, and you have to export it to a new file, all those internal ID’s change. Your CRM record can no longer associate with that QB record, it can’t identify it. That is not a “synch” issue…

      • Without any more information other than, “We think it was caused by some combination of a bug in a QuickBooks add-on (which uses the QuickBooks SDK) and possibly the QuickBooks SDK itself.”, I have had to presume in my response that to be the case.

        The simple point I make and I know it is controversial, is that the concept of sync is outmoded. Any issues of speed of access to data is not about the concept it is about either the efficiency of the SDK/API, the speed of connection or the target database design, in this case QuickBooks. Accessing SQL tables directly is way more efficient than going via the constraints of an SDK or OLEDB but it bypasses the business rules and that isn’t an option. Developers have to use what is offered. However the concept of not moving data between applications is sound, way more efficient to process data in situ and it presents less risk of corruption and the data does not age, it is always current.
        Returning to the actual cause of the problem, it is pointed out that the cause wasn’t identified and probably never will be, however in our use of the SDK we have found it very solid and reliable to date.
        The heart of software development techniques and why developers might choose the option of import/export is that it is far less expensive in development costs to move data around than it is to produce an integrated application in the true sense of the word ‘integrated’, working with the data at source.

        • Graeme, I can only talk about what Intuit lets us do. Within what they let us do, and how the product works, Doug is pointing out a big issue.

          As far as what MIGHT be done if Intuit let us access the tables, well, that would be nice. But they don’t. So we have to work within the framework that is available.

          If we were going to talk about how they SHOULD do things, there are many, many things that I would rather seem them do…

          • Charlie, I guess it was a distraction to have raised the idea of connecting direct to database tables, that isn’t helpful in the QuickBooks context. In our development work we are used to making intelligent choices of working with data directly at a SQL level (high risk but very efficient) or through the SDK (low risk, less efficient). However even within the constraints of using the SDK, a developer can design an integration that is either working directly with the QuickBooks source data file, say for instance to create an invoice and save it immediately, lets call that live processing, vs. creating invoices in bulk, external to QuickBooks and moving them into QuickBooks, at some later time, i.e. batch processing. Another example of the export-import method is to copy data from QuickBooks into another application, manipulate the data and return it, once again a batch process. My assertion is that later method is more prone to error, more so then working directly (live) with the source data. The essential differences are (1) incremental changes versus bulk changes and (2) one data source versus two data sources i.e. the original plus the copy.
            In terms of development effort and hence cost, the additional work that goes into developing a layout or form for every type of document wished to be saved directly to QuickBooks is far greater than assembling the data ready for export to QuickBooks in a batch process. However the impact, should something go amiss is way less likely to be as catastrophic and you are very likley to know immediately that there is an error.

    • Graeme,
      Thanks for your comments. Incremental updates vs. full syncs of all records would definitely make it easier to troubleshoot when/if you get corruption problems.

      However, in the most general sense, the idea of two separate software products exchanging data is, as you say, risky. It’s absolutely the dominant trend that I’ve been talking about (I call it chunkification). But this is a good example of how chunkifying business processes is much harder than unified systems that are all under a single “software roof.” Which is why I think chunkification is somewhat of a pendulum. We’re seeing lots of chunks now, but over time, many of the successful chunk vendors will begin building more functionality into their products so that in the future we’ll start seeing more all-in-one options once again.

      My discovery here was something that I’ve known all along, but it sort of came crashing down on me when I realized the full ramification of having add-ons pushing and/or pulling data from QuickBooks.

      Although my example was about a corrupted file, even if the file NEVER gets corrupted, there will certainly be a day when we want to completely reconfigure every data file to more effectively match the evolving needs of the business. For example, when a sole proprietor incorporates, or when a new division needs separation in the accounting system. Or maybe when you want to weed out old customers, vendors, etc. from the lists to improve performance, or reduce clutter.

      What will happen then? Well, if you start a brand new file, all of the add-ons will want to push all that data back into your brand new file. You may or may not want that, and it’s going to be really difficult for users to control these things.

  • A great informative article. I know that today there are some limitations with QuickBooks Online. But I would not think that other applications that connect with QBO could cause this type of problem in QBO. Or am I missing something here?

    • Jerry,
      Irrespective, of where the QuickBooks data file resides, it is about how the integration works. Is it a progressive update of data in QuickBooks at the time of data entry i.e. is data changed or saved to the QuickBooks data file at that moment or is it a process where data is created or edited in a local data store within the add-on and then bulk updated to QuickBooks at some later time. It doesn’t matter if the connection to QuickBooks is for instance via web services (internet)or via the traditional QuickBooks API running locally.
      The way we make the differentiation when describing how our own integration between ACT! and QuickBooks works is by pointing out that on creating an invoice in CRM, the invoice layout(window)for example, where you create an invoice from within ACT! CRM is a window into QuickBooks, when the Save button is pushed QuickBooks has an immediate update, there is no local storing of data to be uploaded, synchronized, exported or any of those terms that imply a store and forward process having to run.

    • Jerry, as far as QBO, you have similar issues. QBO doesn’t store EVERY item of data you would need. If you have some info that isn’t stored in QBO, that you want to store in your add-on app, that RELATES to some info in QBO, you have this same potential problem. It is the nature of having internal ID’s and separate databases to hold related elements.

      The difference with QBO is that I’m not sure if there is a situation where the internal ID would ever change. It is harder to do that with QBO than in QB Desktop at this time. And, supposedly, the QBO database never gets corrupted?????

      • >the QBO database never gets corrupted?????<

        It better not, since Intuit has not provided any authorized way to restore a previous snapshot, as Doug did with his desktop system.

        Thanks much to you and Doug for this warning! I'd hate to run in to this issue unaware.

        • Wayne, I agree with you 100% – I don’t like the fact that we can’t get a RESTORABLE snapshot. Then again, this is a failing of MANY of the SaaS accounting products, and is not unique to QuickBooks Online.

  • Charlie, what I was trying to point out is in the situation that threw Doug for a loop might not have occurred in QBO. QBO does have some advantages over Desktop and this might be another one of those advantages. Of course the big question mark at the end of your comment is the big unknown!!

    • Jerry,

      Great question. When I posed this question to another cloud accounting vendor, they insisted that a) there would never be any corruption in the data file (ha!), and b) there is now way to clear out old data from the file.

      So that leaves me with a question. What if I WANT to reduce the data “clutter” in my cloud accounting system? If I cannot remove old data, then it starts to feel like data in the app is more like a virus. lol.. 😉 My point is that even if the “cloud apps” are less likely to experience corruption, the issue here goes beyond corruption. I might simply want to reconfigure the data in my data set.

      At this point, I think the only way to do that is to set up a whole new “account” with the cloud accounting vendors. That’s a much bigger deal than simply archiving a file in Windows, and starting a new data file with the data you want to keep.

    • Jerry, we’re in uncharted waters here, a bit. With QuickBooks Desktop, we have years and years of experience, and we know in detail how things work with add-on products. We know that data corruption happens. We have tools and procedures in place to deal with it.

      With QBO, few of us have the same level of experience. In addition, the add-on market is MUCH less developed, mainly because Intuit hasn’t exposed all of the data to add-ons (it is, at this time, much more limited).

      Doug’s situation started because of data corruption, which led to having to move the data to a new company. We can do that in QB Desktop, it is much more complicated in QB Online. The big headache came when the data was transferred to a new company. My point is, if you HAD to transfer to a new company (and could), in any mechanisms we have that I’m aware of, QB Online is going to have the same issue with integrated apps. They are going to rely on that internal ID, and the internal ID is most likely going to change when you migrate data like this.

      I don’t see a difference between the two products in this aspect. The only thing that is different is that, supposedly, we wouldn’t see corrupted data in the first place, and then you wouldn’t HAVE to move the data? Only time will tell…

  • Doug – I think it is great that you have shared your ‘horror story’ with the readers, and of course you and I spoke about these issues several months ago.

    Unfortunately what you speak of is not that unusual a problem, especially when more than one 3rd party application is talking to the same QB file. In addition the problem can be ‘compounding’ since a small glitch in one ‘data transfer’ can spread like a virus in that it infects the QB data, and then travels back to not only the source offending 3rd party application carrying the new corruptions with it, but then that same corrupted data flows to each of the other applications as well.

    This is one reason why I am not a big fan of ‘excessive’ chunkification; the more chunks connecting the greater the risk of corruption, in my opinion.

    While the types of data problems you speak of are not all that common with SDK based applications (and should be even less common with IPP applications) they remain very common with 3rd party applications that still use the iiF import methodology which writes changes to the data without essential forms of internal validation. (And far too many 3rd party specialty products still choose to use iiF as to even develop an SDK interface.)

    Some iiF translators are on the market that offer conversion of iiF format data to the SDK interface and provide validation prior to (and during import); but far too many Users choose not purchase these as a safeguard for their QB data, because their 3rd party developer tells them iiF is perfectly safe.

    Intuit’s use of ‘replication server’ technology for the IPP platform hopefully makes full use of safeguards intended to insure that the ‘internals’ (those behind the scenes identifiers and their associated data objects) always remain static regardless of the dynamic changes to related fields of data (the input or imported data).

    What is missing (regardless of the data integration method) is a comprehensive log of data exchange. While Intuit formerly placed some emphasis on this in the past with SDK developers, they pretty well left it up to each developer to ‘do the tracking for their app’ rather than QB providing a comprehensive log for all data exchanges. Log tracking and error reporting should be an essential component to preserve data integrity. I can’t speak as to any ‘centralized’ IPP related logs that may be retained on Intuit’s App Center servers, but even with such I doubt that there would ever be any ‘user’ based access to such information.

    @Charlie – I am rolling on the floor over your statement: ” And, supposedly, the QBO database never gets corrupted?????”…

    Anyway Doug, your willingness to share your own ‘data disaster’ may go a long way in helping others avoid such issues by checking their data integrity regularly (from both a structural and data character standpoint) because if these issues can’t be prevented, early detection is the next best thing.

    Murph

    • Murph,

      Thanks for the additional insights. This does raise thorny issues for all of chunkification, but frankly, we don’t have a choice about chunkification. It IS happening, and there are compelling reasons to have multiple apps that co-exist and share data.

      Note however that using IIF has no bearing on the specific issue of the LISTID’s that I’m focused on here. If you use IIF, it’s a one way “blast data into QB” approach, and of course we all know that IIF is not really QB integration at all. It’s just a fancy CSV import of data that often corrupts the QuickBooks file. So we nearly always steer clients away from IIF. But IIF doesn’t specifically use or corrupt LISTIDs.

    • Murph, we have to separate the two issues.

      Corruption – many sources of that in QB Desktop. Corruption happens (in QBD), even if you use the product the way it is intended and you don’t use add-on products.

      Integration issues – if for ANY reason, corruption or not, you create a new company file in a way that changes the ID’s, you break how most of the integrated products will work if they are storing data that is associated with QB.

      Limiting chunkification? The problem here is that QuickBooks can’t and won’t do everything that a business needs, so there has to be some degree of interaction with outside products…

  • Charlie, it goes even beyond the years of experience with QuickBooks Desktop. In Desktop I have a few files in which I can experiment with to try to determine a course of action. Obviously Charlie with all of your excellent research that you share with us, you have an assortment of files you use to come up with your findings. I have not found a way to do that with QBO unless I want to pay Intuit for a subscription or use my free PropAdvisor QBOA account. There is one sample file in QBO that I found and it reverts back to its start point if you need to log out and then come back at a later time.

    Doug is right, what he calls chunkification is coming and it is coming fast. Today the calls I get about QBO from end users are no longer the two guys in some sort of service business with one of them in Los Angeles and the other in some other part of the country. Today, I am getting calls from companies that have people in different parts of the country that have 1,000 to 10,000 SKUs. (SOS Inventory can easily handle those numbers) These are young people who are used to the cloud and they don’t want, the high cost of a hosted environment with product license fees costs and user limitations.

    Talking to Tier One tech people at QBOA they say they have never heard of any data corruption in QBO so they don’t think it can happen. I have not talked to any Tier Two, Tier Three or engineers at QBO about Data Corruption so I don’t know what they will say. But in the end the issue comes back to transparency. The work that Charlie, Murph and others do compliments the work that the Intuit Engineers do. Problems are discovered during our Alpha and Beta testing too. Without the ability to do any testing in QBO we, who are on the front lines, are fighting a battle with one hand tied behind our backs. After the issue of losing a file and not having adequate back-ups for that file, Data Corruption is the scariest issue for an end user. Simple small files are not a problem, but these larger files in QBO that may need one or two 3rd party apps may cause problems but who knows? I, and others like me, are hired by end users to navigate their companies through Intuit’s QBO waters but just where am I leading those end users? Am I going to cause them bigger problems than what they have now? I believe Intuit should be clear if in fact there are data corruption issues with QBO if the product is used in some specific way. Of course Intuit could provide us with tools so that we can experiment ourselves.

    • Regarding corruption of the database for QBO, Xero, Wave, Intacct, or any other web application, the idea of corruption needs to be extended to include errant data that was pushed into any of those databases in the “wrong way.”

      For example, if an application connects to any of those applications and puts the wrong data in the the wrong fields, I call that a type of corruption. It may not actually be corrupt in the technical sense, but from the standpoint of users, the data is wrong and useless. So at that point, you’re in the same situation as having a corrupt database. Especially if there is a LOT of data that was put in wrong. What is the user to do? Start over? Roll back to an earlier point in time? Huge issue for real users.

      This is why it doesn’t matter to me if a vendor says their database could never become corrupted. Even if I accept that at face value, what about the other types of “corruption” that end up causing us the same amount of pain?

  • Another area where the problems of list IDs not being the same is when as a consultant, we want to take a copy of the client’s data file and sync it to the new third party application we are configuring for them. We have to be aware that we won’t be able to ‘divorce’ our copy of the QB file from the app and ‘re-marry’ the app to the live QB file without starting a new account with the app for the original QB file to sync to. We have to work with the live QB file at all times when we are working with add-ons that depend on internal IDs.

  • This is one reason I tell my clients to back up their file within the QuickBooks program on a daily basis if they have a lot of transactions or weekly if they have less than a couple of hours a week. I am going to start suggesting that they restore their file once a month on a different machine to test the backups.

Leave a Comment