Overview
Proforma invoice helps customers and internal stakeholders (SalesOps & FinOps) outline expected costs and terms of a sale transaction, facilitating smoother processing. This initiative is to provide an API for applications to create non-legal binding proforma invoices.
Project Info
I led an initiative to modularize "proforma invoice" as an API product adopted by multiple applications.
■ Users & Stakeholders: Sales Operations, Financial Operations, certified installers, customers
■ Tools: Jira, Confluence, Sequence Diagrams, Process Flow Diagrams
■ Technologies: SQL, Splunk, API integration
Achievements
▌78% utilization rate: The proforma API was called for 78% among formal invoices created in the 1st month of launch.
▌2.2 previews per invoice generation: On average, each invoice is reviewed by users twice before submission.
▌31% improved efficiency: Credit note quantity decreased by 31% in the 1st month of launch. Hence, the increase in efficiency.
Problem
▌Inaccurate invoices: Ordering and billing platforms lack the functionality of previewing a work-in-progress invoice. False data points and information lead to inaccurate invoices, which need to be "credit noted" to have a "balanced" book in accounting.
▌Noises in financial reporting: The numerous credit notes and their corresponding inaccurate invoices also introduce noises in financial reporting.
Value Proposition
▌Accuracy: Accurate invoicing to comply with financial regulations and for audit purposes. All sales transactions must be properly documented and can be verified during internal or external audits
▌Modularization: Modularizing the proforma invoice API as an API product allows multiple applications to integrate.
▌Scalability: The feature can be integrated with multiple products/apps to reach more users and solve their problems.
Product Planning
▌User interviews & Requirement gathering:
1) Users and their pain points In the interview stage, I learned how much stress the users have because of not being able to see invoices before generation. I learned the business process and the impact of financial operations and accounting, especially at the end of month.
2) Legal requirements Different legal requirements for a "non-legal binding " document in different countries/regions. I prepared PDF template mockups to seek approvals from legal teams.
▌API schema and specification: I have to ensure no activity for a formal invoice is triggered when a proforma invoice is requested. The specification has to be clear for the engineering team and API consumers.
▌Roll-out plan: Learning who the key users and their regions helped me prioritize the roll-out plan as different regions/countries have localization requirements in invoices.
Solutions
▌HTTP Restful API: The proforma invoice API allows application clients to request a "proforma invoice" by sending the invoice info in the request payload in JSON format. An API specification is also provided so that the data format of parameters and the structure of a request body is clear.
▌Proforma invoice API capability:
1) Tax call: When receiving a proforma invoice payload, the API triggers the non-auditable tax calculation request to a dedicated tax microservice.
2) Proforma generation: With all data points, the API finds the correct invoice template in the template database, fills in the data, generates a PDF, and stores it in DMS.
3) Responses: If successful, the API responds with a proforma PDF. If any critical data points are missing or the request format is wrong, the API responds with an error message to the requestor.
4) Difference from formal invoice call: The preview records are not posted to accounting books nor logged to the invoice database since no formal sales transaction exists.
▌Applications: The applications can use this API in the backend to connect with a frontend component such as a button, hyperlink, or others based on the UI/UX of the application.
▌User Experience: The users can view how the invoices would look like at any point of time before submitting. The legal team also approves the proforma invoice templates as a non-legal binding document. Users (The sales department) are free to share it with the customers.