Supplier invoices
Web App - Streamlining Invoice Management for Small Businesses
See this page for the related Mobile experience.Web App - Streamlining Invoice Management for Small Businesses
See this page for the related Mobile experience.Qonto is a major B2B fin-tech in hyper growth phase, and part of their objectives for 2022 was to gain a deeper and wider audience, through the upsell of existing clients and acquisition of larger SMEs.
Being bookkeeping one of the major key plan differentiator from Basic to Smart, the plan was to provide a solution that would make users switch from accounting and bookkeeping pure players to Qonto.
💡 Keep all your supplier invoices in one place and know exactly what’s due, when, and to whom. Schedule your payments in advance and complete them with just a few clicks.
‍This new feature allows Qonto customers to centralize and process all of their supplier invoices in one convenient location directly from their Qonto account.
- Both paid and unpaid invoices can be bulk imported from a computer, mailbox, or a Google Drive or Dropbox folder.
- Paid invoices and receipts are automatically matched to the correct transactions in History.
- The due dates of outstanding invoices are visible at a glance thanks to automatic data extraction, and customers can benefit from a seamless transfer initiation process with a pre-filled SEPA form.
Large companies have entire departments dedicated to bookkeeping and accounting.
However, for most small to medium businesses and solopreneurs, managing invoices from suppliers is a lengthy and time-consuming process. The first step is to collect and validate all invoices. Then, you need to process and keep track of payments, and export the data for accounting purposes. This results in spending several working days each month managing the status of expense documents.
Qonto's users were not motivated to document information in Qonto nor willing to upgrade because of missing basic features, so they would use third parties for bookkeeping and accounting.
One of the basic missing feature was that we didn't have an overview on the documents related to transactions, invoices and receipts could only be seen as attachments but not independently. Even more importantly invoices could not exist in the UI because there was no related transaction, so users would just keep the documents in their system, without using Qonto.This insight led us to our first problem statement and user story.
Users need a way to ... centralize and visualize invoices so that they can keep track of documents correctly and efficiently.
Below you can see an invoice attached to a transaction. The problem is that before a transaction is made (if users receive invoices from a supplier/client) they have no way to store this in Qonto.
Drive engagement and upsell on Solos by building and activating Invoicing and Bookkeeping.
🎯 Feature success: Reach 500 organisations that have at least 1 invoice in the paid section (manual action from the user, excluding automated processing) within 30 days (M+1)
10% to 20% of late payments are due to incorrect information on an invoice....
Late payments incur a 10% fee in Europe + a 40€ fee per invoice.
Some users still store invoices in paper format, especially in the constructions industry (2% of users)
Most solopreneurs will receive a PDF via email/slack and will keep the document floating around a folder inside their personal laptop.
Others will rely on specialized bookkeeping and accounting tools (Quickbooks, etc..)
Analyzing our competitors to see what different subset of features they have implemented, what we can improve in terms of usability, and understand the product usage from a user perspective.
At this moment we're building a preliminary sketch in low-fidelity of what we want our product to include. We try to forget about UX decisions and UI details, but focus on product features and user flows to identify a possible happy path for our user to reach their objectives.
The competitor teardown, added with this feature guideline exercise provided an additional 5 user stories to implement on top of our original one. All these user stories can be summarized and visualized in the journey below.
Users need a way to centralize and visualize invoices so that they can keep track of documents correctly and efficiently.
Users need a way to easily collect documents from various sources: email, file upload, tax system integration, scraping.
Users need a way to distinguish paid and unpaid invoices so they can settle outstanding debt with their suppliers.
Users need a way to review and validate details of an invoice for accounting purposes.
Users need a way to repair OCR errors, so they can manually reconcile invoices and payments.
Users need a way to easily initiate transfers from an invoice, to better keep track of cashflow.
After individuating all the possible user stories we prioritised them as below. The constraint was necessary because we only had 6 weeks of development resources (frontend + backend).
The selected user stories can be summarized and visualized in the journey below. They fit into 4 main steps for the user: Collect, Review, Pay, Reconcile.
We also designed a scenario for a "happy path" that would guide us in building a prototype for the full experience, taking into consideration the steps a user can go through. This experience doesn't include all possible outcomes, but focuses on the quickest way for the user to achieve their objectives, as defined in our problem statement and user stories.
This step would usually be done in low-fidelity, but since at Qonto we can rely on our design system, we can simply pick and choose from a selection of components already designed in high-fidelity with all states.
The goal is to explore different IA (Information architecture), UX and UI patterns to apply to our overall experience.
Various explorations on how to display the new section in the UI, several back and forth with the design system team, product managers and frontend developers to make sure that the design are effective, feasible, and compliant with the rest of our product.
This section has several data requirements and constraints and will be the basis for all future stories.
Main key decisions on how to display information inside a sidepanel, so that users could double check information in the invoice was correctly extracted. Also figuring out the hierarchy of actions to proceed in the flow (primary buttons vs secondary).
Exploration on how to upload files, using the system finder and adding a drag&drop area. Mapped out interactions, loading and success/failure states.
For collection we implemented sev eral automated ways (email forward, integrations) but we also gave the ability to the users to manually upload files, both via drag&drop and using a file picker.
Since our OCR tool wasn’t performing well 100% of the time, we risked having a high number of invoices that couldn’t display accurate data, resulting in a number of empty rows in the table. This made it hard for users to recognize which table row corresponds to the right invoice.
Another problem was the difficulty in sorting and separating invoices in a way that would allow users to easily recognize the invoice status and perform the relevant action for that user journey step.
For example:
‍
‍Invoice not reviewed —> Review and validate details
‍Invoice validated —> Pay
‍Invoice paid —> nothing to do
We decided to apply something we discovered through our initial research.
Since some users were separating invoices in different folders based on their status (paid or unpaid), we decided to apply the same mental frame and create separate “containers” (in the form of tabs), that would allow users to immediately recognize the status of each invoice and seemingly move one invoice between tabs. This would solve both problems, because we could show different data in different tabs, and still let users sort and recognize all invoices.
When a user uploads a new document, we use automated tools to scan details and match them to the correct transaction (if existing), if a user edits an invoice details at this stage we risk “ruining” the automation link, while at the same time users still need a way to repair incorrectly fetched data.
We introduced a mandatory loading time of 6 seconds to prevent users from editing info while the document is being scanned. After this time the user will be able to see the default sidepanel with details retreived, and if necessary they will be able to edit details (this opens the edit invoice details form displayed above).
During the reconciliation process, it may be necessary to manually reconcile receipts that have been mistakenly recognized as invoices. Even if the problem was an edge case, manual reparation was 100% necessary for these kind of mistakes.
We added a secondary CTA, that would open a modal where user can select transactions (sorted by relevance). Matching an invoice to a transaction would also change its status to “paid”.
Some fields are more sensitive than others, for exampke the IBAN is usually long and more likely to be input incorrectly.
We implemented a dropdown auto-complete selection, in the case the Supplier Name of IBAN hasn't been retrieved successfully, the user can search for an existing supplier, and we will pre-fill the relative IBAN, therefore eliminating risk for manual error.
Once we solved all the hard points, we finalized all screens and flows, not just for the happy path but also for all unhhappy paths, loading states and network errors. Below is a sample for one screen.
We iterated several times to provide a prototype for the full experience that would be aligned between product, design, and tech teams.
We reached our goal of 500 organizations activating the feature in the first month.
We also drove 52 pricing plan upgrades from Basic to Smart+ in the same time-frame, these are counted only from our new landing page, without considering upgrades which happened from other touchpoints.
