{"id":5048,"date":"2020-01-07T10:28:38","date_gmt":"2020-01-07T18:28:38","guid":{"rendered":"https:\/\/www.microsoft.com\/insidetrack\/blog\/?p=5048"},"modified":"2023-06-25T12:50:10","modified_gmt":"2023-06-25T19:50:10","slug":"how-retooling-invoice-processing-is-fueling-transformation-inside-microsoft","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/insidetrack\/blog\/how-retooling-invoice-processing-is-fueling-transformation-inside-microsoft\/","title":{"rendered":"How retooling invoice processing is fueling transformation inside Microsoft"},"content":{"rendered":"
Until recently, processing incoming invoices at Microsoft was a patchwork, largely manual process, owing to the 20-year-old architecture and business processes on which the invoicing system was built.<\/p>\n
The existing Microsoft Invoice platform allowed only manual invoice submission. External suppliers and internal users in Microsoft\u2019s Accounts Payable (AP) Operations team could either email a scanned invoice or PDF, manually enter information into a web portal, or use that portal to bulk-upload invoices using a formatted Microsoft Excel template.<\/p>\n
In some countries or regions with complex requirements, the AP Operations team is required to manually enter paper invoices directly into SAP, Microsoft\u2019s financial system of record. The system worked, but it was inefficient.<\/p>\n
Compared to the wider digital transformation at Microsoft, the inefficiency was glaring. Across the company, manual processes are being replaced with automated processes so that employees can focus on more impactful work. The Invoice Service team, which sits in the Microsoft Digital organization, saw an opportunity in the invoice processing system to modernize.<\/p>\n
The goal was to trigger the creation of invoices using simple signals, like when purchased goods were received.<\/p>\n
\u201cWe started with a question,\u201d says James Bolling, principal group engineering manager for the Microsoft Invoice Service team. \u201cHow do we trigger invoices so that a supplier can just call our API and generate the invoice in a system-to-system call? How do we automate approval based on purchase order and invoice and receipting information?\u201d<\/p>\n
[Read about how we are digitizing contract management.<\/a> Learn how we are using anomaly detection to automate royalty payments.<\/a> Microsoft has built a modern service architecture for its Procure-to-Pay systems\u2014read about it here.<\/a>]<\/em><\/p>\n Lower costs, increased speed, and improved compliance<\/strong><\/p>\n The Invoice Service team is responsible for the entirety of invoicing at Microsoft, Bolling says. The system it maintains integrates tightly with purchase orders related to goods and services from all Microsoft suppliers. The AP Operations team is tasked with ensuring that every payment adheres to relevant payment terms and service-level agreements.<\/p>\n The team also must maintain airtight compliance for the more than 120 countries and regions in which Microsoft conducts business, which accounts for about 1.8 million invoices per year and some USD60 billion in spend, according to Bolling.<\/p>\n The opportunity to lower operating costs by increasing speed and reducing the possibility of human error was enticing, but it wasn\u2019t until the team began tackling a separate project that the scope of what it was about to undertake was clear.<\/p>\n Rewriting a 20-year-old legacy system<\/strong><\/p>\n While working on a tax project, Shweta Udhoji and Guru Balasubramanian, both of them program managers on the Invoice Service team, spoke to customers and partners who used the legacy system regularly. Those conversations revealed the scale of the problem. Roughly 35,000 invoices were being submitted via email every month, with several thousand more coming in through the web portal.<\/p>\n Because validation paths are required for each intake method, they were present in duplicate or triplicate, creating redundancy that made it difficult to add a simple modification. Each change had to be applied to each method individually.<\/p>\n \u201cThe processes are more than 20 years old, and any extensions due to changing global compliance requirements or any other business needs that come in from our partner teams were very difficult to accommodate,\u201d Udhoji says. \u201cWe wanted to simplify that.\u201d<\/p>\n To make matters worse, the team couldn\u2019t rely on documentation for a 20-year-old architecture as they looked for temporary fixes to get the time-sensitive tax updates out the door.<\/p>\n \u201cWe didn\u2019t have any documentation to look at, so we had to test extensively, and once we started testing, we started seeing a lot of problems,\u201d Udhoji says.<\/p>\n The road to the Modern Invoice API<\/strong><\/p>\n Quick fixes wouldn\u2019t solve the underlying problems of the legacy architecture. The team realized that it would need to be completely rewritten to adhere to modern standards.<\/p>\n The Modern Invoice API became a critical component of the broader effort to automate invoice creation and submission where possible. For partners and suppliers for whom manual intake methods are sufficient (or where paper invoices are required by law), those methods would largely remain intact, with some process optimizations added for efficiency. For Microsoft\u2019s largest partners and suppliers, the API would automate the invoice creation and submission process.<\/p>\n \u201cWe knew we could make a huge impact on processing time and the manual effort required to process an invoice. We just needed to automate the process,\u201d Udhoji says.<\/p>\n Because business needs change so much faster today than they did 20 years ago, the API was a business decision as well as a technical one. Modifications and extensions would need to be easy to add to keep up.<\/p>\n \u201cWhat we were building with the Modern API was a framework for better automation, quicker changes, easier automation,\u201d says Bryan Wilhelm, senior software engineer on the Modern Invoice API project.<\/p>\n Bridging legacy and modern systems<\/strong><\/p>\n The challenge that the team faced was daunting and delicate. Because all invoice processing ran through the legacy architecture, there could be no interruptions in service\u2014business must continue as usual, all over the world. The team also needed to be responsive to constantly shifting local compliance laws, too, adding modifications without downtime.<\/p>\n \u201cWe had to first understand the domain, the business requirements, and the technical side of it, while at the same time maintaining the legacy tool and thinking about how to re-imagine the invoice experience,\u201d Balasubramanian says.<\/p>\n The team started by building a hybrid architecture model (as illustrated in the following diagram) on top of the legacy system; initially, the API would simply call the legacy invoice creation pipeline. By integrating with the existing process and building a wrapper on top of it, the legacy system would continue to function without interruption. With so many business rules and validation processes to consider, it would\u2019ve taken a considerable amount of time to write an end-to-end process from scratch.<\/p>\n The iterative approach meant that the team could ship a working API, complete with integration with the legacy system, in just eight weeks. That left more time to gather and integrate early feedback from partners and suppliers while at the same time modernizing the underlying invoice processing pipeline.<\/p>\n Using Microsoft Azure and cXML for interoperability<\/strong><\/p>\n The legacy system runs on Windows Server 2016 and SQL Server on-premises in Azure Infrastructure as a Service Virtual Machines, so the team leveraged SQL Datasync for synchronization between Azure SQL and on-premises SQL Server, and Azure Service Bus messaging for communication between the two systems. The API microservice was built as an Azure function.<\/p>\n