TRANSACTION MANAGER

USING MACHINE LEARNING TO CATEGORIZE TRANSACTION DATA SO THAT CPA FIRMS CAN SCALE LIKE NEVER BEFORE

COMPANY: BOTKEEPER

PROJECT TYPE: NEW FEATURE with continued additions & enhancements

DATES: JAN 2021 - May 2023

ROLE: LEAD PRODUCT DESIGNER

I was the Lead Product Designer for the entirety of the project cycle, starting with strategy, planning, and requirements gathering through to the design phase, prototyping, user research, and handoff to development. I also collaborated closely with our ML team, Accounting Experts team, Product Advisory Board, and leadership throughout the project lifecycle.

BOTKEEPER OPERATING SYSTEM - PRODUCT LANDSCAPE

Botkeeper provides an automated bookkeeping solution to accounting professionals that combines a unique mix of people, process, and machine learning to deliver substantial capacity and efficiency gains. The core offering of Botkeeper is a SaaS platform: the Botkeeper Operating System (BOS). BOS is comprised of a suite of tools and technologies that brings all of the bookkeeping tools and data that a CPA firms needs to power their practice into a singular, easy-to-use, and powerful platform. The goal is to take the tedious, time-consuming, manual, and error-prone pieces of the process and make them more accurate and much faster.

WHAT IS TRANSACTION MANAGER?

Transaction Manager (TxM) is the cornerstone feature of BOS. TxM combines machine learning with some light human assistance to auto-categorize transactions based on past transactions. Transaction Manager functionality has long been used behind the scenes inside the Botkeeper framework by the Botkeeper team, and we now have released a client-facing version that allows us to offer an interactive, faster, and more efficient way to categorize transactions.

THE PROBLEM

Historically, categorizing hundreds of thousands of transactions was a grueling, labor-intensive, and error-prone process. We set out to fix that. We found that accountants’ chief complaints all came back to the same thing: categorizing transactions or something related to that part of the monthly process. Through my initial research, I also found that the accountants we spoke with spent somewhere between 50% and 70% of their time on transaction categorization; that includes reaching out to a client with questions, looking up receipts, looking at historical transactions, and more manual tasks.

Another problem that I was tasked with solving was the necessity to create a singular interface on the front-end that worked seamlessly with 2 very different GL-providers (QBO and Xero) on the back-end. It was extremely important that we provide a uniform experience in TxM, despite which GL-provider that a partner or client was using. I had to ensure we accounted for all transaction types that are found in QBO and in Xero in the interface and that we also supported the same suite of actions in TxM that either provider offered on their platform. The goal was to eliminate any need for a user to navigate outside of BOS and/or TxM.

THE USERS

We have a unique user stack that we have to think about for each feature that is part of the overall Botkeeper Operating System experience.

We have a team of internal accountants and accounting experts that help augment the staff of our partners and provide additional accounting support as needed.

We also must try to satisfy the partner CPA firms which make up our primary target audience; these firms are the users that are paying a recurring fee to access the platform that is based on the number of clients they migrate to BOS and other variables in each firm’s practice.

We also cater to the clients of our partner CPA firms. In most cases, the firms white-label the platform so that their clients are unaware that there is a 3rd party involved in the accounting process. A minority of firms do communicate to their clients about Botkeeper and the platform. Each firm is different in terms of how much access they give their clients to the platform or how involved they are in general in the accounting process.

THE SOLUTION

Transaction Manager 2.0 is the result of the synthesis of our discovery and research. TxM combines machine learning with some light human assistance (only when needed or requested) to auto-categorize transactions based on our extensive dataset of past transaction data.

The key aspects of our solution needed to ensure:

that our users trust the machine learning to do the work and do it accurately
that the machine learning model is accurate with a high confidence value the majority of the time (also allowing for improvements over time due to continuous re-training of the model)
that when the prediction does not have a high confidence value (98% and up), a person is able to step in and assist
that users still have the ability to have their own input and ability to edit or change the data for any transaction (also allowing for users to help “teach” the model)
that users have the ability to configure and customize the TxM experience to best meet their needs and preferences
that there is visibility into what exactly the ML model is doing so that is does not seem as scary to some of the more non-technical users
and that users are able to move through TxM quickly and efficiently

THE SOLUTION: PROCESS & METHODS

RESEARCH:

Diary studies and ride-alongs with members of the BotOps/Accounting Experts team and with CPAs from our partner firms
Identification of key pain points
Competitor Analysis
Feature audit of integrating GL-providers (QBO and Xero)

DESIGN & ITERATION:

Mapping the UX flow
Collaborative design sessions
Rapid wireframing
Prototyping

FEEDBACK:

Design reviews with stakeholders (internal and external)
Multiple rounds of user testing
Frequent critiques with fellow designers

THE SOLUTION: KEY FEATURES

AUTOPUSH & TRANSACTION CATEGORIZATION

AutoPush automatically posts transactions from the Smart Connect bank feeds into QuickBooks Online. Using our Machine Learning models, we predict the payee and category for a transaction. Any transactions that are low or medium confidence will automatically appear on the “Open Inquiries” tab for your review.

Low-confidence transactions will have a red AutoPush icon next to the “Category” and/or “Payee” fields; medium-confidence transactions will have an orange AutoPush icon next to the “Category” and/or “Payee” fields.

High-confidence transactions will appear on the “Processed” tab and will have a green AutoPush icon next to the “Category” and/or “Payee” fields. If you hover over the AutoPush icon, you will see a tooltip with additional details.

You can also see the confidence level in the transaction details window by clicking the “Action” button, and then the “Details” button.

Confidence Levels

This ensures that we're providing an interactive and transparent experience into what's happening under the Botkeeper hood, and empowers our firm client to help 'train' the machine as to how to improve on the details of the data in the future.

There are three different confidence values:

High confidence (98%+) - transactions are automatically categorized, pushed to GL and show up on the Processed tab in Transaction Manager.
Medium confidence (90-97.9%) - transactions are automatically categorized, pushed to GL and show up on the Needs Review in Transaction Manager.
Low confidence (0-89.9%) - transactions are automatically categorized, pushed to GL and show up on the Needs Review tab in Transaction Manager.

EDITING & REVIEWING TRANSACTIONS

In TxM, you are able to select one or multiple transactions to bulk edit more than one value at a time.

MATCHING

Matching is the process of linking bank feed transactions to their corresponding GL transactions. The three types of matches are duplicate matches, invoice/bill matching, and undeposited funds matching.

It is very common for our clients to require matching for their transaction categorization. Matching is used for preventing duplicates and tracking AR/AP. The three types of matches are:

Duplicate matches occur when an existing transaction in the GL matches a bank feed transaction; these transactions are excluded from further processing because they have already been recorded and posted to the appropriate accounts.
Bill/Invoice matches occur when the bank feed transaction (bill payment or invoice payment) is linked to an existing GL transaction (bill or invoice) that has been marked paid when the balance is $0.
Undeposited Funds matches are used when payments received from customers have not been deposited to the bank account yet. When we match to one of these undeposited funds transactions, a deposit is created which reduces the Undeposited Funds balance and increases the bank account balance.