Amortisation & Revenue Recognition
Amortisation is an accounting concept that asks accountants to split the cost of a prepaid expense over the months it relates to. This project aimed to ease that burden by automating those monthly entries in Wafeq. I owned the work end-to-end, from research and problem framing through product strategy, PRD, design and iteration with Engineering, then extended the same thinking to Revenue Recognition, which became a paid feature.
Wafeq users were manually calculating and posting recurring accounting entries every month, and a single missed entry could leave the books inaccurate until close.
Automate that recurring work without taking away the visibility and control accountants need over their books.
Here are the key features we shipped
The workflow was fragmented, which led to missed entries.
Accountants were using Wafeq's Bill module + Excel + Wafeq's manual journals to calculate and recognise prepaid expenses and deferred revenue every month. A 12-month prepaid expense meant remembering to post the correct entry every month. Miss one, and the books could remain inaccurate until close.
The cost wasn't only time. A missed entry meant a P&L that overstated one month and understated another, and the error usually surfaced at close, when it was most expensive to fix.
I conducted 6 in-depth user interviews to uncover current workarounds and pitfalls.
I spoke with 6 accountants and financial analysts to understand how they were handling prepaid expenses and deferred revenue. Three main issues came up:
My first assumption was that automation needed its own space.
I explored a dedicated Amortisation and Revenue Recognition module in the side menu. Users could create a schedule, configure the accounts and dates, and let Wafeq generate the recurring entries automatically. It solved the automation problem on paper. But before committing to the structure, I wanted to see whether accountants understood how it fit into their existing workflow.
The interface worked. The mental model didn't.
Users could create a schedule, but struggled to understand how it connected to the accounting transaction behind it.
The standalone module had recreated the same separation users were already dealing with between Excel and Wafeq. So I changed the direction.
Designing with workflow, traceability and control in mind
Instead of creating another destination, I brought the experience into the existing accounting workflow.
The bill became the starting point. From there, users could create the schedule, understand what would be recognised over time and see the journal entries it would generate. The source transaction, schedule and resulting journal became one connected workflow. The goal wasn't to remove accountants from the process. It was to remove the repetitive work while keeping them in control.