Vijay Yivaturi

Case Study: On average Amazon Payments team handles around 15,700 tax-related payments per month through 17 different tax payment platforms, valued at ~794 USD million. This is a combination of Indirect taxes (ESS, AWS, Retail), Direct tax, Corporate Income Tax (CIT), Withholding Tax (WIT), Property tax, etc. The centralized payments team is located at Hyderabad and entire end to end operations were performed by them. Their role and scope of work is to create a vendor number and on-board new tax vendors based on the inputs provided by respective compliance departments. They also edit or modify the existing details in the current vendor details (that were already on boarded – changes like payment currency, payment method, bank account details, address, point of contact). The payments team scope of role is extended to initiate the penny testing to ensure that the set up is good to go. Once the actual tax payments are initiated from different regions (NA, EMEA, APAC, MENA) they ensure the payments are completed, retrieve the payment proof by working with banks, save the payment proof, and notify the compliance teams. Their scope is also extended to work on returned payments from bank, re-investigating the reasons and re-initiating the payments. The payments team also investigates past payment queries during compliance audits. They also cancel the duplicate invoices or incorrect invoices in the system. So, this end-to-end process was handled by a single team till 2024. Challenges: The payments team could not meet their deadlines for reasons listed below: 1. Entire end-to-end i.e. from vendor onboarding till payments completion stayed within payments 2. One person\employee handling multiple cross border regions led to long working hours 3. Too much manual intervention delaying the payments even though the work flow is right 4. Acting as treasury department for high dollar payments, getting additional approvals 5. Poor controls while initiating payments resulted in rework as well as penalties 6. Lack of appropriate training and documentation within the payments team 7. No handy details of compliance contacts resulted in delayed or pending communication 8. No automated triggers or workflow designed, and full manual process set up 9. Multiple payment platforms in place need to monitor and track the payments. Solution designed and implemented: The current Payments team is split into multiple sub teams and redefined the scope of work 1. Vendor Maintenance: This team is responsible for tax vendors on boarding. This includes new entities under existing countries and new countries and entities. This team is responsible for modifying the tax vendors details for existing vendors based on the inputs provided by compliance. 2. VIVAA team: This team is responsible for highlighting and stopping the duplicate tax payments. This team ensures that the payments workflow is designed as per chart of accounts mapping model and ensures that the payments are picked and paid through OFA system 3. Payments Team: Payments teams are now designed based on regional models i.e. NA, EMEA, MENA, and APAC. Considering the geo timings and workload (based on 2022 and 2024 data), the team is split into four and headcount is allocated to handle the payments by balancing the workload. APAC payments team will be available in the early hours of the day and work till afternoon timings, where EMEA and MENA payments were handled by afternoon to evening shift teams and NA payments were handled by night shift teams. 4. Payments Inquiry Team: This team scope is to investigate the payment proofs, also act as mediator between banks and compliance teams to investigate payment delays, misses. Provide notification on mandatory and optional holidays, bank holidays with compliance across all regions. They also provide any changes in bank payment methodologies to compliance team (Nostro accounts). 5. Treasury Team: The scope of treasury team is to maintain the funds in respective banks and currencies for high dollar payments. 6. Payments On Hold or Invoice on Hold (IOH) team: The scope of this team is to identify and alert the compliance team about tax payments that are not processed or stuck due to any sort of mis mappings or duplicates, or stuck due to technical issues. AI Tools Designed: 1. Tax Payments Platforms: Introduced three main tax payment platforms (1). Tax Obligation Manager (TOM), (2). Payload and (3). CRTR (Creature). This helped to track the payments from three platforms instead of 17 earlier. 2. Wikis: Self-Explanatory wikis are created and updated with detailed steps\screen shots and point of contacts from each team along with escalation matrix to be followed. 3. Payee Central App: The Payee Central app on FinOps Central provides internal users with access to Corp AP related features such as inviting new payees to Payee Central, searching existing payee details, searching invoice and payment status, and managing invoice holds. 4. Simple Issue Manager (SIM): The SIM tool developed with AI-assisted model tracks and summarizes the payments status in a user friendly and consistent format, covering key aspects such as the problem statement and the root cause analysis performed by the payments team along with audit logs (time stamps). 5. Visual Dashboards: At each team, visual dashboards were installed for tracking the real time payments status 6. Monthly Business Review (MBR) meetings: MBR’s conducted between Compliance and Payments teams based on the metrics with an objective to raise the awareness of challenges and issues with payments flow and to provide feedback on improving the three payment tools and communication channels. Results: Post segregating the workload between the teams, the results were outstanding. The waiting is reduced from 3 days to 0.5 days. Payment’s accuracy is measurable and outstandingly increased i.e. 99.6% - NA payments, 99.1% - EMEA payments, 98.2% - MENA payments, and 99.3% - APAC payments. Penalties were reduced (from financial impact on cost centers). Employee work life satisfaction scores improved. Employees were given opportunities to rotate between roles which helped them to learn, perform and grow at Amazon by increasing their network

During each month-end close, OpEx Accounting is responsible for posting AP (Accounts Payable) Unposted line entries to the GL (general ledger). AP Unposted lines result from invoices that are placed on hold and not posted to the GL because they can’t be matched to a PO (purchase order) and receipt. This could be because there is no PO# on the invoice, conflicting information on the invoice vs PO. During the month, AP investigates to try and match invoices to POs and determine the right GL coding, so they can be released for payment and posted to the GL as an expense. However, since this can be difficult, coding is often assigned to the wrong cost center, location, or account, and many invoices remain unresolved. Hence, AP will prepare a consolidated report of all non-postable invoices send it to OpEx to use for further investigation and posting the final journal entries. OpEx communicates with Finance Partners (FP’s) who research and reach out to business partners to determine the right coding. FP’s then e-mail OpEx with GL coding change requests and OpEx adjusts the entries one by one. Close to 200 line item adjustment entries are manually created each month. Furthermore, in order to permanently correct coding on future invoices, trouble tickets must be submitted to both AP and Procurement. However, it is observed that many FP’s ignore to update the trouble tickets. As a result, the same invoices end up re-appearing on next month’s report, and are continuously coded incorrectly. This is a time-consuming, unscalable, and error-prone process that undermines operational efficiency, as well as the reliability of financial reporting. Root Causes Analysis: AP Error: -When the invoice is coded incorrectly even if: -there is a valid PO# listed on the invoice -bill to/ship to entities match on both the PO & Invoice -vendor/supplier match on the PO & Invoice -line items, quantities, and $ amounts on both documents match -When the total of invoice distributions does not equal the invoice amount entered in OFA Vendor (Supplier) Error: -When there is no PO listed on the invoice, or the invoice is invalid (may also be listed as 'Invoice over $10,000' <-- invoices over $10K need a valid PO on them to be processed) -When there is no PO, and the PO requestor cannot be found (applies to invoices that don't require PO or are under 10K, also listed as 'Non-Postable: Workflow Needed, or 'Unable to find requestor') -When there is an invalid distribution/bank account for the vendor (also listed as ACH Reject) Business (Amazon's) Error: -When the PO is missing the cost center, tax, or other line items -When the release # for an invoice is not created on a PO (Each release # corresponds to a line on a PO. For each release, the vendor will send the desired amount of goods/services on the PO line corresponding to the release # and also send an invoice for it) -When the business hasn't added more money to the PO, when they know they have placed orders exceeding the remaining PO amount -When the business places an order before having a fully approved PO Unknown: -When the quantity billed exceeds the quantity received (could be business or vendor error) -Unable to match items/judge which lines to match (Unable to match invoice to PO for various reasons) -When the vendor/supplier on the invoice doesn't match the one on the PO (could business or vendor error) -When they are different bill to/ship to entities on the PO vs Invoice (could be business or vendor error) -When the invoice price exceeds the purchase order price (could be business or vendor error) -Duplicate invoice Solution: An automated metrics dashboard was created to assist AP and Procurement with their analysis and efforts to minimize unposted lines. Meetings were held with both teams to ensure OpEx was providing metrics with appropriate root cause analysis (refer below for Root Cause Analysis). The current dashboard is split into 4 areas: Hold Category Metrics, Supplier Metrics, PO Requestor Metrics, and Coding Change Metrics. Users can view the number of unposted lines and $ amounts per hold category, supplier, and requestor, as well as the lines and $ amounts for coding change requests per hold category and root cause. This aids in identifying whom to contact and what problem areas to focus on first. (i.e. if there is a PO requestor with a large quantity of unposted lines under their name, they may need to be trained on how to properly prepare a PO requisition). Benefits •Compliance: The metrics dashboard helps pinpoint root causes of error, so action is taken to prevent future on-hold invoices stemming from the same reasons, ultimately reducing unposted lines. Reducing lines allows more invoices to be released for payment so expenses can be recognized in the period they were incurred in. This increases timeliness and relevance of financial data, and is in accordance with accounting’s matching principle5. •Transparency: The metrics dash board provides a much better audit trail and more simplified way of tracking, as opposed to searching through e-mails in order to recall and justify coding changes. This improves our trust and relationship with stakeholders3, and mitigates audit risk. •Customer Obsession: AP and Procurement no longer have to sift through countless tickets to fix each invoice/PO. This metrics dash board consolidates all errors into one list that can be sent to both teams to ensure coding is fixed for any future or unpaid invoices on the same PO. •Efficiency: Allowing FPs and AP team to review their errors saves the time spent by OpEx investigating and revising. The extra time can now be used to thoroughly review support for coding changes, assist team members with other pressing close issues, and conduct more detailed reviews of journal entries to ensure all are posted correctly. Benefits: Time Saving – Effort saving of 1232 Hours/Annum

Context: In Amazon, FOAA (Finance Operations Account and Analysis) Bangalore team is responsible for preparing and submitting the balance sheet reconciliations in Account Reconciliation Module (ARM) tool monthly. There are 16 teams in FOAA Bangalore. Each balance sheet account reconciliation has two levels of review i.e. Reviewer 1 (internal - Bangalore) and Reviewer 2 (external) – Central Accounting teams. It was identified that out of 212,966 annual reconciliations submitted by preparers, reviewer 1 had rejected 17,581 i.e. 8.26%, these were classified as L1 rejections. In similar, out of 149,114 annual reconciliations submitted by preparers, post reviewer 1 review and approvals - reviewer 2 had rejected 2,255 i.e. 1.51%. Total rejection rate was 9.77%. From the total rejection list, it was not clear the reason for the rejections. Automating Rejection Reasons in ARM tool: Currently, FOAA BLR team approach the L1/L2 reviewers of respective teams to provide the reasons for rejections. This process is completely manual and very subjective. Reason being, the complete analysis depends upon the L1/L2 reviewers’ comments on the reasons. This is not a scalable approach to evaluate. I designed the rejection reason codes post analyzing the manual inputs provided by both reviewers, followed by I developed the rejection reasons codes in ARM (drop down menu) as below. Both reviewers 1 and 2 must select the right category of rejection from drop down and proceed with rejecting the account. The model is very scalable, tracks timely and auditable for future reference. Major Rejection Categories List: 1) Missing\Inappropriate Authoritative Supporting Document (ASD’s) updated in ARM or in reconciliation spreadsheet (ASD enhancement) 2) Missing\Inappropriate or incorrect classification of reconciling items 3) Missing\Inappropriate explanation (commentary) updated in ARM 4) Incorrect dates updated – impact on aging of the reconciling items 5) White board journals (above $250K correction journals) impact during quarter close 6) Reconciliation assigned to incorrect reviewers 7) Incorrect Supporting documents\links updated or unable to open the links and attachments 8) Missing\Inappropriate action plan to clear the reconciling items updated in ARM 9) Reconciliation rejected by error 10) Not submitted on time or missing deadlines Framework established to track performance metrics: Based on the rejection reason provided, it is observed that, on average, 21% recons due to ASD enhancement, 18% recons were rejected by error, 16% recons due to format enhancement, 14% due to incorrect classification or categorization of open items, 12% recons due to commentary enhancement, and 10% due to invalid supporting links. I developed a framework to monitor the L1 and L2 rejections monthly. This mechanism allows FOAA teams to categorize rejection categories and set up monthly review meetings to understand the root cause of rejections and take proactive measures to avoid future rejections. The control mechanism consists of: 1) Maintaining a tracker of reconciliation rejection categories. 2) Monthly review with FOAA leadership to provide the details of rejections. 3) Identify the repetitive recons which were rejected in the past two months with similar rejection reason. 4) Conduct brainstorming sessions and control measures to avoid rejections 5) Documenting the reconciliation rejection scenarios, impact and control measures for training purposes 6) Adopting best practices which were implemented in other areas to reduce rejections. ARM Reconciliation Status Dashboard: A live visual dashboard is displayed to track the reconciliation completion status at each team level and raise flags on due dates. The tool is designed to download and publish the metrics to leadership monthly and provide updates on goal status. This ARM (AI) tool reduced the metrics preparation time and provided more accurate details. In planned phase manner, we reduced Level 2 (L2) reconciliation rejections in ARM from 1.51% to 0.35% (on a TTM basis) and thereby delivering a 90bps YoY improvement which is calculated as (Total L2 rejections\Total number of accounts submitted for L2 approval) x 100 In similar we reduced Level 1 (L1) reconciliation rejections rate from 8.26% to 2.25% (Total L1 rejections\Total number of accounts submitted for L1 approval) x 100 These two metrics (time and quality) helped to evaluate not only the team’s performance but also individual performers (within the team) on quality aspects and decide the annual rating, promotion cycles, and hikes.

Context: Determining the tax mapping rules for tax calculation in Canadian provinces ESS (non-resident) entities that has multiple tax rates for sellers and buyers who are having registrations\exceptions to be followed based on country specific rules in the below three regions. This is one of the most difficult phases in Indirect ESS taxation and the following is an interesting case study. PST Province - British Columbia: Non-CA resident (‘Foreign’) service providers supplying 15,000 CAD (11K USD) of in-scope digital services will be required to register, collect and remit BC PST at the standard rate of 7% to BC-based customers. BC PST is a sales and use-type tax. The rules in BC do not distinguish between B2B and B2C transactions i.e. both B2B and B2C supplies are in-scope and subject to BC PST at 7%. Certain customer-based exemptions may apply. GST\HST Province - Canada Federal: Non-Canadian resident (‘Foreign’) service providers supplying in-scope ESS to CA based customers must register, collect and remit GST/HST at the standard rate for 5% for customers based in Quebec and British Columbia provinces. There is a GST/HST registration threshold for foreign service providers of ESS and marketplace operators amounting to CAD 30,000 (approx. USD 22K) over a 12-month period (both prospective and retrospectively). Where a business or digital platform operates with a simplified GST/HST registration, the rules distinguish between B2B and B2C transactions, where only in-scope B2C transactions will be subject to GST/HST of 5%. However, where businesses or digital platforms are registered or proceeds to register under the regular GST/HST regime, all goods/services sold will be subject to GST/HST regardless of the B2B/B2C distinction. QST Province - Quebec: The legislation provides that supplies of digital goods and services made to consumers in Quebec by companies not located in Quebec and which are not already registered to collect QST be taxed at the standard QST rate of 9.975%. Further, GST/HST registered non-resident businesses which are not already registered to collect QST under the existing QST regime will be required to collect QST at 9.975% on sales of physical goods to consumers in Quebec. The registration threshold is $30,000 CAD (approx. $22K) of in-scope supplies made to consumers in Quebec in the preceding rolling 12-month period. Consumers are defined as people (individuals or businesses) who ordinarily reside in Quebec and are NOT registered for QST (i.e., generally B2C transactions). Residency can be determined by using two non-contradictory pieces of information QST registration and address. Whether a customer is considered a business consumer can be determined by requesting the customer provide a valid QST number. If a valid QST number is provided, then QST is not required to be charged. Post updating the tax business rules, threshold amounts, tax rules, tax rates, along with exceptions, customer & seller locations (address), tax registration numbers, AI perfectly created the logic's. However, the preparers ignored the tax calculations provided based on AI’s logic. In fact, they have overridden the calculations and applied incorrect rates and remitted tax to the countries as below For British Columbia PST registration, they applied 5% GST rate instead of 7% PST - resulted in underpayment of approx. CAD $4.9M For Quebec QST registration, they applied for 5% GST instead of QST 9.975% - resulted in underpayment of approx. $24.7M For British Columbia and Quebec provinces under Canada Federal, they applied PST 7% and QST 9.975 instead of GST 5% - resulting over-payment of approx. $48.9M It was identified that the tax calculations provided through AI’s logic were accurate and later ended up in amending the filings by paying penalties and interests. In the above example, AI provided accurate tax calculations, however for the second example, AI was at flaw while designing the balance sheet liability accounts where my team blindly followed AI’s recommendation and ended up posting balance sheet reclass journals. Region Tax Type and Rate Correct Balance Sheet account for liability Incorrectly recorded in multiple accounts Amount (CAD) British Columbia (BC) PST – 7% 26113 26435 $4.8M 26111 $1.1M 26427 $3.4M Canada Federal (BC and QC) GST\HST – 5% 26435 26113 $9.7M 26436 $19.3M 26111 $22.5M 26427 $34.3M Quebec (QC) QST – 9.975% 26436 26435 $54.M 26427 $41.6M 26111 $2.3M AI is supposed to design the balance sheet liability mapping based on region and tax rates; however, it also referred to additional "logic" or "terms" such as sales (26111), non-resident (26427), virtual location (26435), resulted in the incorrect balance sheet mapping. This had a high impact on balance sheet account reconciliations and ended up in rework and posting correction journals for almost 7 months. Post investigating the root cause, I fixed the balance sheet tax mapping rules that resulted in right liability account allocation. At any phase, it is recommended that the teams should thoroughly understand and study the AI’s logic proposed before entering production phase which avoids rework and financial impact, This saves time and avoid unwanted attention from tax departments. Any overridden calculations should be thoroughly reviewed and approved and accordingly the AI’s logic's should be amended with proper approvals in place. The same must be documented in SOP's to avoid error repetition. It is suggested to build flags in the AI tools to highlight the overridden tax calculations changes (by referring to country specific examples) to both preparers and reviewers so that there will be controls before approving the final tax amounts.

Case Study: Smartphone Discount Optimization - Amazon Great Indian Festival 2023 vs. 2025 Executive Summary: During Amazon's Great Indian Festival (AGIF), smartphones represent the highest-revenue category, contributing approximately 35-40% of total electronics sales. This case study examines how AI recommendations guided discount strategies, where they succeeded, where human override was critical, and the resulting business impact. Amazon faces a multi-dimensional optimization problem during AGIF smartphone sales such as (1). Brand partnerships - Negotiated discount caps with OEMs (Samsung, Apple, OnePlus, Xiaomi), (2). Margin protection - Maintaining profitability despite aggressive discounts, (3). Inventory management - Balancing stock across fulfillment centers, (4). Competitive pressure - Matching/beating Flipkart's Big Billion Days pricing, (5). Customer acquisition - Converting first-time smartphone buyers, (6). Same-Day Delivery promise - Ensuring SDD fulfillment at scale. AI decisions and suggestions were trusted for Hourly Price adjustments based on Real-time data processing, inventory positioning based on Pattern detection at scale, and customer segmentation by studying hidden behavior discovery. Human decisions (Override AI) are implemented while deciding the Brand-specific strategy – considering the Relationship & negotiation factors, Margin protection through multi-stakeholder trade-offs, Discount timing psychology is override when studying the behavioral economics, statistical interpretation during sample size & context awareness, and Competitive response - Real-time market intelligence Quantified Impact Summary Value Created by Trusting AI: AI-Driven Decision Revenue Impact Margin Impact Dynamic hourly pricing +$89M +$7.1M Inventory optimization +$42M +$3.8M Personalized discounts +$67M +$5.4M SDD routing efficiency +$12M +$4.2M Total AI Trust Value +$210M +$20.5M Value Created by Human Override Human Override Decision Revenue Impact Margin Impact Apple strategic discount +$107M +$3.2M Xiaomi margin protection -$38M +$4.25M Flagship discount timing +$61M +$2.8M Total Override Value +$130M +$10.25M Combine Optimization – Total Incremental Values (2023 à 2025) Incremental Values Revenue in millions Margin in millions AI-Trusted Decisions $210 $20.5 Human Override Decisions $130 $10.25 Total - Combined Impact $340 $30.75 Attribution Analysis: Revenue Growth Attributed to Framework: 95% of USD 356 million total growth Margin Improvement: 0.9 percentage points (8.2% to 9.1%) AI Contribution: 62% of total value created Human Override Contribution: 38% of total value created Key Learnings: When to Trust vs. Override Trust AI When: 1. Processing millions of transactions in real-time 2. Detecting patterns across pin codes 3. Optimizing within defined constraints 4. Speed of decision exceeds human capacity 5. Historical patterns are strong predictors 6. Objective function is clearly defined Override AI When: 1. Strategic relationships are at stake 2. Competitive dynamics are fluid/real-time 3. Behavioral psychology factors apply 4. Statistical conclusions contradict business materiality 5. Multi-stakeholder trade-offs exist 6. Novel situations outside training data 7. Qualitative factors can't be quantified MBB Reliability Framework: 1. AI systems can be used for data collections by studying transaction logs, clickstream, inventory. 2. For pattern detection AI models can be used for customer segments and price elasticity. 3.It is the joint responsibility of an AI and MBB for statistical validations (T-tests, regression, significance testing). 4. At the stage of Contextual Interpretation MBB holds the major responsibility. 5. During Strategic Integration, both MBB and leadership holds a major responsibility (market share vs. margin trade-off). 6.MBB's post validating AI outputs against business reality can finalize the Reliability Assurance Conclusion: In smartphone discount optimization during AGIF 2025, AI recommendations delivered $210M in incremental value through pattern detection and real-time optimization. However, human override decisions contributed an additional $130M by incorporating strategic relationships, competitive intelligence, behavioral psychology, and contextual interpretation of statistical results. The optimal approach is neither blind trust nor reflexive override, but a structured framework that assigns decisions to the entity—human or AI—best equipped to handle them.

Case Study: Amazon Online Sales for Mobiles (Electronics) post implementing Machine Learning Category 2020 2021 2022 2023 2024 Electronics 15% 10% 5% 8% 17% During 2020, the COVID-19 lockdowns restrictions forced online shopping with store closures, and no offline alternatives were available. The demand for mobiles increased due to Work from home implications. During 2021, we saw a continued growth through retaining customers with sustained online habits by offering more product choices and improved logistics with faster delivery. In 2022, we identified the pattern of reduced spending due to high inflation, product availability due to supply chain issues, slowly resuming to offline shopping (return to stores). In 2023, we identified moderate growth due to international markets expansion, new product launches with stable prices. During 2024 we identified steady growth based on AI recommendation post studying the customers pattern in online shopping better cross-selling AI recommended smart bundle recommendations such as phone case, wireless earbuds, fast charger, screen protector with a bundle discount of 15%. 1. Based on user data, Machine learning was embedded to personalize recommendations based on product purchase history, online browsing history, search queries, session duration. 2. Post data collection, the next step is embedded with AI model processing through customer segmentation, product affinity analysis, demand forecasting and price optimization. 3. Based on the above model, AI or machine learning helped in designing Cross-selling execution i.e. product page recommendations, carte page suggestions, email campaigns and push notifications 4. The main step in continuous improvement is through tracking conversion rates, measuring revenue impact, gathering feedback and retrain models. Machine learning helped to analyze customer patterns based on model selection, phone features, performance monitoring, customer reviews, battery, price comparison, brand priority. Based on demand, machine learning helped to design dynamic pricing concept through discounted prices i.e. 20-40% off (discount range) on lightening deals, which attracted a greater number of buyers. This machine learning also helped to understand the customer payment methods\options that helped to tie up with different banks with multi payment options. AI helped to study the customer choices of best-selling mobiles like I phones (22-24%), Samsung Galaxy Series (19-21%), One-Plus devices (2-3%) and Xiaomi & Redmi phones (12-13%). Overall, Machine Learning helped Amazon in identifying the Smartphone Market study with customer behavior insights. It also helped with ‘Better recommendations’ for Cross-selling conversion rates, ‘Smart bundling’ through Average Order Values, ‘Personalization’ through customer lifetime value, and finally ‘Relevance improvement’ through ‘Recommendation Click Rate’

Company: Amazon Domain: E-Commerce Business Context: Amazon maximize their sales through offering Same-Day Delivery (SDD) which increases Average-Order-Value (AOV) without significantly raising delivery costs, while ensuring high customer satisfaction. During Amazon Great Indian Festival (AGIF) period - at high level Amazon Same-Day Delivery works as follows: Customer Places order for items marked “Same-Day Delivery eligible” – Order processing – Packing and Picking, Delivery Assignment, Last-Mile Assessment – Delivers to customer’s doorstep. Case Study: Amazon Great Indian Festival Metrics (Diwali festival season in October) 2023 vs 2025 Metric 2023 2025 Trends Sales in USD – billion 11.68 14.26 22% Average Order Value (AOV) 43 52 21% Metro Cities Covered 3 5 Pin Codes Delivered 18463 21743 18% Fulfillment Centers 118 269 128% Sortation Centers 43 117 172% Delivery Stations 102 497 387% Sales and Average Order Values (AOV’s) deal with large volumes of data based on continuous financial metrics and were measured based on counterfactual baseline over years and analyzed the correlation patterns between SDD uptake and AOV. Sales (2023 – $11.68 billion vs 2025 - $14.26 billion) were compared using Paired T- Test and results, there is no statistically significant difference between Amazon Great Indian Festival sales performance in 2023 and 2025 at the 95% confidence level (p = 0.390), even though the trends showcase 22% increase from 2023 to 2025. Average Order Values are calculated as: Total Revenue / Total Number of Orders. A Paired T-test was conducted to compare Average Order Value between 2023 and 2025. The mean AOV increased from $43 to $52. The test showed a statistically significant difference (t =- 11.3, p = 0.001, a = 0.05). Therefore, the increase in AOV is both statistically and practically significant. Grounded on Paired Analysis (paired t) we observed Average Order values improvements based on data design of pin codes, metro cities and product categories. With regards to expansion i.e. Metro cities from 3 to 5 and pin codes from 18463 – 21743, applied regression and multiple regression models. We replaced hypothesis testing with our internal system modeling. Using capability analysis, the cost per order is measured which suggests process capability improvements through routing, batching and delivery slot optimization. Based on above data, MBB methods and AI tools helped in identifying the hidden shopping patterns in customer behavior i.e. easy to predict who buys and opts for Same day delivery for products such as Amazon devices (Echo, Fire, Kindle), Furniture, Fashion (Clothing and Shoes), Beauty (Skincare), Toys and Games (Kid’s products mainly aged between 7-12 years). This helped to design top deals across various products with affordable finance options. Another dimension assisted to identify is the customers pattern who opted for same day delivery who tend to buy higher-margin electronics and home-appliances, however the same day delivery costs spiked disproportionately due to late-night deliveries, and this was not identified due to limited options while doing manual testing. Apart from Segment-level analysis between pin codes & delivery slot, an additional correlation analysis was performed between costs (logistics) vs delivery pin codes and peak time delivery hours. To speed up the same-day delivery, we investigated the delivery timing patterns with logistics team and redesigned the delivery timings using time-series analysis from late at night to morning (8 AM to 11 AM), midday (afternoon 12 PM to 4 PM) and evening (5 PM to 9 PM). This aided to detect the cost of hotspots. To reduce costs and meet Same day delivery event, we worked on establishing and expanding fulfillment networks i.e. increased Fulfillment centers (FC’s) to 269 from 118, sortation centers (SC’s) to 117 from 43, and delivery stations (DS’s) to 497 from 102, advanced inventory placement, and engagement with local last-mile partners (transportation) led to increased customer satisfaction metrics on meeting the same day delivery parameter. Between FY 2023 and FY 2025, the Amazon Great Indian Festival growth experienced a data established AI-enabled decision-making, when administrated with robust data-credibility checks, and drove non-linear growth in revenue, customer reach, and reduce cost efficiency. It is a proven fact that hypothesis testing alone is insufficient where Master Black Belts must redesign experiments, prefer paired and segmented analysis, apply casual modelling method by reducing mean comparison. Statistics provide variances and trends whereas an MBB must provide reliability.

Yes, DMAIC still holds a bigger picture. Domain: E-commerce Executive Summary: In 95 Countries, we made TAX (AWS, ESS, and Retail) payments as below: Year 2022 – USD 47,962 million Year 2023 – USD 55,392 million – 115% YoY increase when compared with FY 2023 Year 2024 – USD 61,232, million – 111% YoY increase when compared with FY 2024 The above listed payments were processed through 136 unique banks in 95 countries. Out of 136, 43 (32%) were direct payments (without intermediary bank dependency - but involved multi-currency payments) and 93 (68%) unique banks must process the payments to tax department with the involvement of intermediary banks. Out of 93 banks it was further identified that 39 banks had to make the payment through one intermediary bank and 54 banks had to make the payment through two intermediary bank accounts (local banks due to country\multi-currency dependencies). Waiting time was identified as one of the top reasons for payment delays directly impacting the penalties and interests, followed by banks or tax portal system maintenance or server issues (system latency issues), human errors (incorrect processing), and other technical dependencies (lack of full information about payments). For FY 2022, a total of $2.35 million was paid towards penalties - $1.4 million, $479K as interests, $239K as bank fees (including direct and intermediary banks), and forex conversion fees as $191K. During 2023, a total of $2.71 million was paid towards penalties - $1.6 million, $553K as interests, $276K as bank fees (including direct and intermediary banks), and forex conversion fees as $221K. An increase in trend of 115% when compared with FY 2022. In FY 2024, a total of $3.01 million was paid for penalties - $1.8 million, $612K as interests, $306K as bank fees (including direct and intermediary banks), Forex conversion fees as $244K. An increase in trend of 111% when compared with FY 2023. It was a very difficult stage to set the bridge from the external parties like banks, intermediary banks (financial institutions), tax department (Government authorities) and Amazon payments\treasury and tech teams. Factors like geographical and time zone differences, language dependencies, people movement\availability, communication channels (telephone\FAX\Email\in person meetings), Forex (currency conversion) involvements, cross tie up between banks and intermediary banks and tax departments, banks\tax departments (mainly in African countries) follow old methods (not migrated to advanced technology), some banks and tax portals were in the stage of digital transformation caused delays while streamlining the process. Waiting time (to reflect\apply the payment against the filings submitted in the respective tax portals) triggered auto penalties, interests and the daily changes in FX fees in the tax portals. Apart from these barriers I and my MBB did examine to understand the country-specific laws related to bank policies and FX conversion policies and need to ensure they all adhere and set-fit during the transition phase. A team of 90 with clear roles and responsibilities were involved right from defining the problem, measuring (quantifying) the financial exposure (funds outflow), analyzing the problem root causes with the facts provided, improvised or re-built the payment process with banks, reduced the dependencies on intermediary banks and implemented controls at each stage. Post implementing DMAIC techniques between the internal and external teams the leakage was controlled. First, we involved payments and treasury team to discuss the challenges and possible solutions with the banks (external) and reduced 78% dependencies on intermediary banks. This saved the cost of $559K (68% decrease) in bank wire fees. Once the dependency is eliminated, the payments processing time is reduced from 5 to 2 working days. This helped to reduce the 91% payment penalties, and 95% late interest charges. We involved top leadership at VP level to deal with tax departments officials and changed the filing currency mode (country currency) and in parallel we made the payment currency set up in Amazon systems in sync with the country specific currency which saved 55% of Forex fees. DMAIC’s core principles are problem solving through systematic methods based on data driven solutions, followed by decision making and through continuous improvements and of course AI will be a powerful tool that will make each step more accurate, effective and insightful.

My MBB and I played a major role in transforming the ‘Payment’s tool’ and improving the ‘TAX’ payments process. During 2022-2024 - 17,646 (5882 payments per year) tax payments were processed through ‘CRTR’ (Creature) tool. For each payment execution, the processing time taken by preparer is estimated at 15 minutes (including excel latencies). Each Analyst\Preparer must fill around 28 mandated parameters in an excel template from three different sources (1). Payee Central tool and (2). Chart of Accounts from Frames site and (3). Manual inputs. Payee Central tool is managed by Vendor Maintenance team, and they store 13 details of each Tax department i.e. department name, department registration number, filing currency, payment currency, payment method, payment instructions, tax department’s full bank account details (including Swift code), intermediary bank, bank charges, FX charges, International Bank Account number (IBAN number). The second input is updating the 7-segment (Company-Location-Cost Center-Account-Product-Channel-Project) payment GL string details from Frames site managed by Central Accounting team. The third component ownership is with tax preparer (Compliance team) has 8 inputs i.e. update the invoice number (no specific invoice format), invoice amount, entity tax registration number, payment description, line description, invoice date, payment due date, payment reference number (a unique alpha numeric number generated post submitting the filings in the tax portal). Post updating these details and payments initiated, the CRTR tool will validate the parameters (in the back end) and the estimated validation time is 15-20 minutes for each invoice. The CRTR tool throw errors to the preparer if any. There is no visibility from which component the error triggered from. Preparer must download the template again, validate each parameter and re-submit in the tool post deleting the prior uploaded payment template. Even if all the parameters were matching it was very difficult for the preparer to identify what exactly was missing. An extra ‘space’ would also be treated as error and not exactly match. The estimated time to re-work and correct the errors is 5 to 7 minutes and the re-estimated validation time remains constant at 15-20 minutes for each invoice (validates from first component till last component instead of validating the revised parameter). If there aren’t any errors - the CRTR tool push the payment to ‘approve’ queue by generating a CRTR request number. The preparer must notify the CRTR request number to the payment approvers through email (no standard format followed) to approve the payment. Once approved, the payment approver must notify the preparer through email (a complete manual process). The waiting time at this stage (of course with no structured email) is between 3-5 minutes depending on the availability of the preparer and approvers. My MBB and I worked backwards and collected each payment unique rejection reasons from the above listed 28 mandated parameters, identified additional tools and teams’ dependencies. Post brainstorm sessions My MBB and I designed a new AI tool - TAX Obligation Manager’ (TOM). The tool is designed in 5 components (visible in a single window) capturing information from Master data and auto populating into (1) Entity registration details information, (2) vendor (tax department) information from Payee central tool, (3). 7-Segment payment GL strings from Frames site, (4). Excluding invoice number, invoice amount and payment reference number columns (which are unique each month), invoice parameters will be auto populated. To avoid duplicating invoice numbers the new tool is configured with combination of Company\entity name + tax registration numbers. + tax filing period (unique each filing period). Standard line and payment descriptions are auto updated. Invoice date will be auto populated based on payment initiation date and the payment due date will be auto captured with a buffer of 5 days based on tax department payment due date captured from master data file. The new tool was also designed to raise reminder flag to preparers\reviewers and approvers based on filing due dates and high dollar payments (above 2 million as threshold). Out of 28 mandatory parameters, 25 parameters were automated\auto populated with embedded control checks, and the remaining 3 parameters i.e. invoice number, invoice amount and payment reference number columns (which are unique each month) are to be updated manually by preparer. Post designing, implementing and improving the new tool payment processing time has come from 15 to 2 minutes. In addition, we also made enhancements to the new tool to trigger auto notifications from preparer to reviewer with a standard payment instruction format along with payment approval hyperlinks. During ‘Improvement’ journey phase in 2025, MBB and I played a very crucial to identify the current process gaps, acted as a bridge between the technical department and non-technical teams (compliance in my case), guide the transformation from manual process to fully automated solutions. Through additional dive deep and by working backwards I am confident that MBB’s will help to reinforce production deployment mechanism through planned and tactical actions. The above study is a classic example of it.

My team is responsible for preparing 5882 filings annually for 913 companies\nonresident entities registered in 64 different countries for ESS (non-resident) filings manually. Ideally 490 filings will be prepared manually by a team of 10 i.e. each of them has to prepare 49 filings. These 490 filings will be reviewed and approved by myself. Briefing about preparing the ESS (non-resident) filings steps manually at high-level, the first step is: Analysts (preparers) make a copy of prior filing spreadsheet to current period folder and rename the file to current month name. Analysts will delete all prior period data from current obligation spreadsheets and do necessary edits in all six tabs. Overriding errors identified during this phase which impacted the quality of the filings during Output (incorrect calculations) being ended in re-work. Then each of my team member downloads both summary and transaction detail reports for their respective entities based on country\entity\period\registration\ using specified parameters. Post downloading, the raw reports were saved in respective obligation folders. Considering huge volumes of data my team faced a lot of waiting time (min – 20 minutes to max 90 minutes) to download summary and transaction detail report. Moreover, time-out error is also a bigger challenge while downloading the reports. The second challenge is the file size (the transaction detail – minimum file size is 30 MB and maximum as 2.5 GB) not excel compatible and was crashing the spreadsheets. The transaction details reports are needed for General Ledger Account Reconciliation and for Audit purposes to ensure that the invoices are recorded in the respective General Ledger accounts as per chart of accounts. Preparers must provide explanation why few of the Sales invoices were excluded (based on country laws exceptions). Preparers has to investigate the reasons for invoices that were also missed to record in the General Ledger (most cases incorrect GL booked due to mapping of incorrect GL or missed out posting or cut off time in the systems). Preparers must provide information to accounting team to post re-class journals or correction journals accordingly. Once the reports are ready and available, the preparer copy and paste the transaction details, followed by ‘refresh’ pivots in ‘analysis’ tab. During this phase identified multiple human\manual errors while copying paste or while refreshing the pivots. (Usually pivot data is not fully captured based on incorrect selection in the raw data). Tax analysts must validate (check) the taxable products and tax codes (PTC’s), the tax rates, service indicators (B2C or B2B), destination, currency codes, net amount, net VAT amount and any other required columns in transaction detail reports. Tax analysts also ensure to validate the data refreshed in ‘pivots’ with the source data. Tax analyst also considers the revenues from external sources (apart from regular reports) and will add to the main revenues. Tax analysts will check the formulas in filings spreadsheet and update them accordingly to pick the correct values (control check on excel formula’s). The finalized taxable revenue will be copied to ‘revenue analysis’ tab. The revenue analysis tab has rolling twelve months’ data which helps the tax analysts and reviewers to compare the revenue trends with prior periods (during this manual preparation time there weren’t any graphical data representations). Post applying month end FX rates (Denominational currency), the taxable revenue is updated in ‘Return submission’ tab. Tax analyst will provide a detailed analysis in ‘GST payment process’ tab explaining the payment, payment approval due dates, Preparers need to provide the reasons for fluctuations in trends and notify the reviewer to review. The above-mentioned steps are similar while preparing each obligation manually, apart from specific exceptions being followed based on country\Geo-based tax rules i.e. Reports Generation, Compilation and Consolidation Data Validation Reconciliation Return Preparation Download Invoice copies for review Submit the final work papers for reviewer (myself) and approvals The above was the process and pain points presented to the leadership through one year time allocation survey and quality impact at 77% i.e. based on inputs provided by each preparer and error count by each preparer during preparation (documented by reviewer). I conducted continuous brainstorming sessions with in the team and with my first level manager. I presented a six pager documents metrics covering for a time period of one year. Initially there was a push back due to budget and other priority project constraints, later, they approved and supported this initiative. Post leadership approvals – I engaged my team and started working with Technical team support and through multiple AI tools automated most of the process steps through such as (1). Auto downloading of reports with the parameters based on each country and entity at desired date and time. (2). Auto-roll forward of workpapers with required naming conventions and saving to respective shared drive under each country\period (Year\Month format) (3). The current period data will be auto populated under respective six tabs (4). FX rates will be auto updated in FX tab for multiple currencies along with conversion (5). Pivots will be auto refreshed (6). Trends are updated with graphical representation and highlights which products need leadership and business team attention (7). Check and validate the report parameters like tax rate, jurisdictions, taxable PTC, Net Amount and Net VAT Amount calculations, valid registration details, taxable Product code or not and as per law or not. (8). In addition, based on the report, top 25 invoices (based on amount criteria) will be auto downloaded and saved in the drive for review mechanism. These eliminated manual intervention in areas like roll over work papers, compilation & consolidation, and data validations (formula’s, refreshing pivots, inserting or deleting rows in work papers, links). Pre-defined ESS tax logic's were established based on country specific tax laws \ entity jurisdiction rules that provided accurate taxable revenue and GST\VAT payable Easy comparison on MoM, QoQ, YoY trends and variance analysis. Easy to highlight the areas where focus is needed and make specific notes for reviewers and final approvers (this helped to understand what customer focus or approach is). Grabbed quick attention through data representation. Post analysis, it was identified that the quality of the filings improved from 77% to 98% and helped to reduce 3 of the headcount to move them to different streams based on their interest and the existing work load was able to manage by 7 headcount with stress free - maintaining work life balances. At each step, myself and my leadership were engaged in continuous discussions with the preparers and tech team during testing phase, checking the desired outputs. The ownership was clearly distributed between my technical team and my team. My team and myself took full ownership while designing the inputs to the technical team while updating in AI tool. We didn’t onboard all countries and entities at one stretch, this was completed at multiple phase level understanding the errors during pre and post launches for each 15 countries. It was a difficult phase to present and share the automated work papers to tax and audit departments where they were equipped with manual work papers. Even though the budget for this entire project is estimated at $850K, it went up to $ 1100K which my leadership approved the excess based on the phase 1 and phase 2 successful impact. The real challenge is the patience and the commitment of both Technical as well as my team to get this successful even though we slightly crossed the budget. Even now if we face any new tax law change or new rules implemented, we update the technical team to update the new laws or rules and make the changes according to which is an ad-hoc support basis and was approved by the leadership. The above case study explains the roles of leadership while leveraging while automation