Receipt Reconciliation Web App

My role: Design the hi fidelity wireframes, document and hand off wireframes for developers, collaborate with developers, test design with users, iterate.

Duration: 6 month

Team: 2 designers, 9 developers, 1 product owner, 1 scrum master

ABOUT RECEIPT RECONCILIATION

Receipt Reconciliation is a process that accountants use to reconcile the receipts with invoices for the closing that they do every period and then quarterly. Its a huge part of what the accountants do daily: they find out of balances and investigate them. First they need to understand the cause of the out of balance, next they need to fix it to avoid future out of balances. They look at lots of data and do it in Oracle reports or Legacy tools, that are data heavy and difficult to use.


We were working with manufacturing department. Even though we limited the scope to one department, we still dealt with a lot of transactions. Because the amount of transactions in manufacturing is very high (millions) the amount of reconciliation that needs to happen is also pretty hight (hundred thousands). Finding the transactions that are incorrect, and cause OOB (out of balance) in legacy systems becomes more and more time consuming. To a point that it became not sustainable. This is where our team was tasked with building an alternative - that will allow filtering and finding data easier, would be user friendly and truly serve the accounting needs.

PROJECT GOALS

I have joined the project after the research phase of the project has started already. What the team has learned in this period is that accountants have a very hard and very important job. They do dozen of activities and require correct data , easily accessible at the time that they need it. Our goal was to identify main problems they are having with reconciling invoices, and to design a solution for them.

We have identified these things as areas of opportunities:

  1. They are looking at massive data tables, and looking through them manually is very difficult and time consuming (because who can go through 50 000 lines of transactions to find the one that is wrong every day?!)

  2. When researching a specific transaction they need to see any additional information available. This means looking through data in a different tool and on a new screen. In some case one accountant may have 10 different tools open to research one transaction. Some of the issues with that were:

    1. difficulty to go between tools (they all look different)

    2. loosing the transaction line in the sea of lines

    3. load time for each tool (things would crash).

  3. Accountants often do their research on a few items at a time and leave their notes, or questions in their notebooks or on sticky paper. It was getting a bit confusing when you have to find notes from a few month back. And in case any one else needed to pick up work or join the team - it was nearly impossible to fill new people in on the details of some transactions.

Kroger is driven by OKRs - and as a team we embraced this approach to set meaningful targets for this project.

Our Objective was - to improve reconciliation experience for accountants in SCMFA (Supply Chain Management Finance and Accounting)

Our Key Results were:

  • Show data in one place

  • Provide ability to filter the data by criteria that are most meaningful to accountants

  • Allow ability to compare certain data sets

  • Improve the human error factor

  • Provide easier scalability of these data sets

Our approach was very lean. We listed out all ideas that can solve the problems accountants had. Then we did an importance difficulty matrix to identify what can we do for the MVP version.

Based on this we have decided to create a tool that would host all the same data the accountants need, but improving how they search and research it. There were a lot of ideas, and we broke them into 2 groups: must haves for MVP, and nice to haves for V1.

The main features and functionality for the new Receipt Recon tool MVP version were:

  • the data table needs to have a clear distinction between in balance and out of balance items

  • search and filter by:

    • out of balance

    • specific devision

    • period and year

    • certain dollar thresholds

    • PO number.

  • commenting

  • export into Excel

  • drill down details in collapsable rows

As accountant chooses the department they need, they need to choose the division that they are working with.

They would see the data table, with red and green highlights indicating transactions that are in balance or out of balance.

To see transactions per specific period or by a PO number, they would use the filter above the table.

Accountants can easily download data table to Excel with Export button.

Commenting was one of those features that we heard of almost at every call we had with accountants. And when we delivered they were beyond excited.

We were using Company Design System (KDS) and so there was a little need for the low fidelity work - since we could grab and experiment with available components. That being said, the design system didn’t have a data table component for us to use so we were designing that from scratch. But the general styles and colors were applied from KDS.

We shared the first iteration with our team, looking for feedback and suggestions, discussing feasibility. After that first round of iterations we were sharing the wireframes with the accounting team in a weekly call, to make sure things look right to them, that if there are any misunderstandings of their needs or tasks, we could catch it right away. The accounting processes are complex and the way accounting is done at Kroger is unique is many ways - so we had to ideate on the way we show data per transaction.

Some of the decisions that we made as a team going forward is to create a reconciliation application that could host data for not just Manufacturing department, but essentially a place for any department to use for the reconciliation.

As accountant chooses the department they need, they need to choose the division that they are working with.

The drill down detail was another functionality that accountants were very excited about. We designed the table with expandable rows that would show more data on the selected transaction. Not only they could see everything in one screen, but we also selected only the data that are relevant to their research tasks (vs seeing all data in legacy tools with ton of things that are not needed for the task at hand). And we have also highlighted the key lines to be able to scan the data and instantly find what they need.

Overall it was a huge success for the accounting team. It has streamlined their work, added value and simplified their workflow.

What went well

We have built a tool that has significantly improved the work of our very busy accountants.

We advocated for the needs of accountants and got an approval from stakeholders on adding things like commenting to our MVP, even though the original ask was to build lean.

We delivered the features that we set out to in the MVP.

What we could have done better

We had a difficulty between design to development hand off: the developed application was often not quite like the designs, even though Figma has all specs available. There was a lot of back and forth. We figured half way through the first quarter of the project that our devs are not comfortable to use Figma, and did a demo going over everything they need to know. Which improved the hand off a bit, but there was a lot of waisted time tweaking color or corner radius.

This project took longer than anticipated and we had to extend the original timeline.

Thank you.