Brain-Dead Xero Machine Learning ridiculously incomplete, Payments, Part 3 of 5

Filed in Accounting, Business by on January 5, 2018
Brain-Dead Xero Machine Learning is ridiculously incomplete in not using PAYMENTS.

Brain-Dead Xero Machine Learning is incomplete because it works with income. Most companies now quickly do its new Machine Learning income job with a very few manual (pre-Machine Learning) rules. Xero currently hypes Machine Learning speed, saying it is 80% right within three or four passes. That terrible result only applies if you assign all income to sales and a few other income accounts. Xero Machine Learning is very slow if you must correct each receipt for a different Account Receivable subaccount. That is, it is slow to correct each wrong entry for a different customer and is very slow if it must run many Machine Learning rules for different item descriptions.

We know about this slowness because the Xero CTO wrote that the href=””>line item description search… seriously bloated our index size ” so he removed it from the Xero Global Search and Replace (Find and Recode). Therefore, the current Xero fast Machine Learning speed hype is so misleading that it borders on fraud. Of course, this will not be the first time Xero misled users nearly fraudulently. A Xero Machine Learning keynote, at its 2016 U.S. convention (17 months ago), let many users believe Xero Machine Learning was already a reality. We only later learned that it was a year or so away.

Companies new to Xero may use its trivial and incomplete Brain-Dead Xero Machine Learning for income, but I will soon write about why Xero Machine Learning is very Brain-Dead by design. Companies also often have 50 or more times as many payment accounts as income accounts. Many payment accounts are for MANY payees. We always can use restaurant, bar, grill, pizza, bistro and similar wildcard terms to assign all these to Entertainment. However, Xero Machine Learning does not use wildcards (or help us use them) in different companies. Brain Dead Xero Machine Learning only learns from each of an endless series of manual (slow, eror prone) corrections, which users must make IN EACH SEPARATE COMPANY.

Here is a not so ridiculous example. Joe’s Bar, Pete’s Bar, Mary’s Bar, Joe’s Grill, Pete’s Grill, Mary’s Grill, Joe’s Pizza, Pete’s Pizza, Mary’s Pizza and countless similar partial duplications will soon EACH go to Entertainment. Thanks to the Brain-Dead Xero Marchine learning, they MUST EACH DO THIS IN SEPARATE XERO MACHINE LEARNING RULES FOR EACH COMPANY. Xero users will then need FAR MORE WORK (when payments make Brain-Dead Xero Machine Learning not ridiculously incomplete). As discussed in Part 2 of this series below, it will take Xero a very long time to fix these and other BRAIN DEAD MACHINE LEARNING problems if it ever does.

Xero users also are very unlikely to soon get all their rules in Excel (or in similar form). Excel or similar reviews would let users quickly, efficiently and accurately analyze, compare and change many Xero rules. I know, from terrible personal experience (Part 5 of series) that Excel rule reviews let you instantly sort by payee, account or other fields, for extended comparisons, analysis, and changes. Xero, however, only lets users see ONE RULE at a time. This horrible limit perpetuates errors. Even when you find transaction errors, nothing in Xero shows you which rule caused the problem. With so many payment payees, it takes a long time to correct mistakes by repeatedly searching each of many rules. Xero rules also only apply to already imported entries, so you must slowly and separately correct each transaction error AND each rule error.

Xero may soon create a separate Machine Learning rule for each payment account and each payee, in each company. Users should be able to use wildcard rules to quickly, easily and accurately minimize this incredible mass of Xero Machine Learning rules. Otherwise, the massive number of Brain-Dead Xero Machine Learning rules will make Xero terribly slow. The chief Xero programmer (CTO and co-founder) recently documented that this slowness is already a critical problem in his global search and replace (find and recode). He had to partly turn off the existing “…line item description search… seriously bloated our index size. I knew it would come up – I can obviously see it’s value – will be a good one to track.” Therefore, the Xero CTO also should know that this will be a terrible problem for his Brain-Dead Xero Machine Learning (more soon). We may soon ask if a grossly excessive number of Brain-Dead Xero Machine Leaning rules is slowing Xero to a crawl, or if many wildcard item descriptions, plus a defective line item description search, is slowing Xero to a crawl?

Xero and QuickBooks Online (not QuickBooks Desktop, a big nail in the Desktop coffin) let you easily create and change wildcard rules manually. Some entries may be wrong, but QuickBooks Online has been correctly assigning around 90% of applicable entries for some time, while Brain Dead Xero Machine Learning still only processes income. QuickBooks Online users also can use its long proven Reclassify Transactions function (courtesy of QuickBooks Online Accountant users) for fast, easy and almost error-free changes of QuickBooks Online entries and Machine Learning results. The slow, often buggy and perpetually incomplete Xero global search and replace (now “Find and Recode”) is the best example of why Xero programmers are misdirected, slow and incompetent. My next post (Brain-Dead Xero Machine Learning by Design) will soon document this conclusively. To the contrary, QuickBooks Online users have long been able to instantly copy rules to other companies and to and from Excel, for a vital sort, compare and change analysis.

For more soon, please subscribe to the QuickBooks-Blog.

For related posts, click on:

1. Horribly Brain-Dead Xero Machine Learning, programmers are misdirected, slow and incompetent.)
Brain-Dead Xero Machine Learning will persist, Xero culture denies problems instead of fixing them
Brain-Dead Xero Machine Learning ridiculously incomplete (this post)

Comments are closed.