As an accountant, sometimes you perform certain tasks over and over that you wish they would somehow perform themselves or that there was a way to automate all of them. But wait a minute, that would mean that there will be no work for accountants and as a result, they would become redundant, right? No, they won't, instead, they will become more efficient to focus on accuracy and more strategic tasks.
Early 2019, as I was looking for a free accounting software, I came across several solutions but Wave accounting stood out. Mainly because it provided an option of scanning and uploading receipts so that I did not have to enter them manually amongst other features.
I used to download all receipts received on email, scan hard copies, upload all of them onto the system and voilà, the system picked all the details on the receipt that my work was only left to verify and post them to accounting.
Sadly, I started feeling frustrated when I received invoices from suppliers because I had to do them manually. Unfortunately, the Wave accounting app does not support the bill upload feature even as it supports receipt upload. For non-accountants, a bill is an invoice from a supplier normally payable after a given agreed period of time while a receipt is a document you receive when you buy goods or services in cash.
After struggling with this problem and after being pestered by a friend several times, I set out on a mission to try and find a solution to this challenge. Nobody commissioned me to do it, so it was unsolicited.
The design was purely based on my experience as a user, and later on, as a designer using the app on my 14-inch laptop screen and the experience of people in my circle. I did my very best to keep the look and feel of the overall design of the app intact by thinking through every single detail and step.
To give it some structure, I broke my work into three steps: user research, feature design, and the results. Below is my work process.
1. User research
I talked to seven accountants and went to the Wave Community forum to find out what other users are saying. Below are excerpts from the community forum page.
From my research, I zeroed in on three fundamental user pain points below:
User Pain points
- Inefficiency - Users spend a lot of time creating bills especially if there are too many goods or services rendered in one invoice.
- Less Accuracy - For accuracy, some users print all bills including those received electronically so that they can enter the details as they tick each item off.
- File Storage Limitations - Users are forced to keep hard copy documents for audit at the end of the year. Physical files normally take quite some space when they are too many. When they are lost then the user would have no backup especially if the invoice was a physical copy.
2. Feature design
I further broke this part into two, first the information architecture and second wireframing and prototyping.
a) Information Architecture - Sitemap
My main goal with designing the sitemap was to set a smooth path for the user from the time they land on the dashboard to when they save the bill and successfully post it to accounting. I tried to replicate the already existing sitemap but modified the bill section to include the new feature.
Here is what I came up with.
b) Wireframing and Prototyping
I decided to test the depth of the waters by first sketching out some paper wireframes as below;
Next, I turned the paper prototypes into mid-fidelity prototypes using Figma as shown below;
Next, I set out to work on the high-fidelity prototypes. I used inspiration from the app's already existing receipt upload feature to design the bill upload feature. My main aim for doing this was to keep the development team at Wave in mind since they had already worked on the receipt upload feature and incorporating this into the already existing designs would not be too tasking. I used my knowledge of accounting to assess how the accounting entries would be executed backend.
3. Results
a) The dashboard
Just like it is right now in the Wave app designs, this is the landing page and the user can then navigate to any part of the app from here. So in this case the user will click Bills under the purchases icon the normal way to navigate to bill creation screen.
b) Bill Creation
I redesigned the bill creation screen as follows;
- I replaced the create bill button with Enter bill button and provided two options in a dropdown menu for uploading a bill or entering it manually. When a user selects enter manually, then the current design as is in the app takes precedence. When a user selects upload bill, the app opens the upload feature that enables the user to navigate to files storage location on their computer to select and upload bill.
- Created sort categories to enable a user to view bills as they need based on upload status. They can see all bills, those that are still processing, those that are ready to post to accounting and those that have been posted to accounting. A user would just need to click on a bill to open it.
See the screens below:
c) Verify details
Once the user has selected the bill to upload, just like the app scans the details on receipts, it should scan the details on the bill. The app should then read through the bill and pick all the relevant fields such as Vendor Name, Invoice Date, Invoice due date, item or expense category, the amounts and the taxes.
If the app does not pick the details, as is the case in this example, then the user has the option to correct and add these fields manually. This way, at least we will have solved the pain point number (c) above of storing supporting documents together with the transactions.
Control should be put at this point such that when a user selects item then the expense category greys off and when they select the expense category the select item box on the same line greys off.
If a bill is clear enough, then the app should be able to pick all the relevant details as below.
If the user is satisfied with the details below, they can save by clicking the post to accounting button.
d) Successfully saved
As soon as the user clicks post to accounting, a success message pops up, and then the app navigates to all bills screen so that the user can view and open the bill as they so wish.
The relevant accounting entries
I wanted to be as comprehensive as possible and hence took an example of a trading company that trades in beverages. I picked the Coca-Cola Company as a supplier of beverages for this case. In the invoice, there are two items i.e. Fanta 500ml and Coke 500ml, and the delivery fee charged. The next assumption was that these goods have been delivered on credit with thirty days credit period. So here are the corresponding accounting entries;
- Add the quantity of Fanta 500ml purchased to Fanta 500ml inventory bin card/ledger in this case 20.
- Add the quantity of Coke 500ml purchased to Coke inventory bin card/ledger in this case 25.
- With the total delivery expense of EUR. 10, Debit the relevant delivery expense account with EUR. 8.77, Debit the value-added tax account withEUR. 1.23 and Credit the vendor called the Coca Cola Company.
- With the total cost of purchase of Fanta and Coke items in this case EUR. 60. Debit the relevant Cost of goods account signifying purchase with EUR. 52.63, Debit the value-added tax account withEUR. 7.36 and Credit the vendor called the Coca Cola Company.
See below for more details:
Preference Testing
Given that, the app already has a feature that functions almost the same as my proposal. I decided to do preference testing on the two screens below.
Using usability hub, I shared the link in various accounting Facebook groups and got the results as below.
Most respondents preferred screen A that places the action buttons side to side but in the end, I decided to go with screen B which is similar to the Wave appl screens. However, I would advise Wave HQ to feel free to use screen A as preferred by most of the users.
Reflection of my work
Something that began when I was unable to upload an invoice into an accounting app ended up being a two weeks exciting activity that saw me take off my accounting hat, roll my sleeves, put on my design hat to find a possible solution for users of Wave accounting software. With this design, I see that I have been able to address the user pain points identified above as inefficiency, Less accuracy, and file storage limitations.
Although I understand that there are several considerations that Wave HQ would have to make before thinking of taking this into account, it was a great learning opportunity for me to stretch my problem-solving ability by combining my design and accounting skills to come up with a design that could be implemented to solve an actual problem.