Electronic Invoicing using D365 Finance and Operations

Business Pain Points

Based on the IRB, the requirements, seller to send sales data via E-invoice and buyer to secure copy through IRB’s portal

1. Identifying transactions which for which E-Invoice or Self-Billing is to be processed
   • B2B sales to sales and foreign customers through lead ERP
   • Self-Billing to foreign and domestic purchases through lead ERP
   • B2C- E-Commerce sales though E-Commerce portal.
   • POS sales from Company owned stores though POS application.
2. For submission of data
   • Method to issue E-invoice and collect buyer details
   • For Self -billing - If buyers provide E-invoice, then “Self-Billing” is not required.
3. Data submission timelines
   • Real time or within 72 hours
   • Validation of invoice on Government portal in real time

Out of Scope

• Transactions at Franchise stores
• Sale of Fixed assets
• Debit notes and Refund notes
• Customer stakeholders have decided to not share mode of payment and other payment details as these are “optional information”

Solution

Validation from ERP to Middleware

• Along with working on day-to-day issues implemented enhancements which were on hold since long with in short period which helped to increase work efficiency.
• Customer and Vendor - contact details
• Tax registration details - validity as on date of transactions
• Buyer Identification details - BRN, SST and MSIC numbers
• Transaction details - Currency, Item, quantity, sales prices, tax, transaction date and document number, tax types, classification codes

Validation from Middleware to Government Portal

• Customer/Vendor - TIN number validation
• E-invoice and Consolidation status check
• E- Invoice status submission and response

Design

1. Implementation of Middleware for receipt of data from multiple data sources
2. From Lead ERP to Middleware

   1. Identification of Business Processes

      For E-Invoice Transactions

      1. Sales Order - Invoice and Credit notes
      2. For non-Sales order transaction - Free Text Invoices and Credit notes

      For Self-Billing Transactions

      1. For non-Purchase Order - Invoice Journals

   2. Data transfer to Middle ware

      1. Medium of data transfer was using the API of Middleware
      2. Handshake between middleware and lead ERP - based on connection tokens provided by the middleware, both system were connected and connection was tested by transferring limited set of data.
      3. Trigger of data transfer was posting of Transaction in D365 Finance and Operation

         For e.g. - On posting of sales order invoice or free text invoice or Accounts Payable invoice Journal

      4. Format of data which in which it is transferred to Middleware
         • Every API has specific template or list of fields
         • Before developing the data set for API, data mapping activity between API fields and fields on transaction and master data in the lead ERP was carried out
         • Data Header - eg contains Customer/Vendor information, document ID, contact information
         • Lines - contains Item, quantity, price, tax etc
         • Payload Request - On posting of transaction, payload request is generated which transfers data to D365FO
         • Response

   3. Monitoring of data

      1. Creation of Repository - Log form was created in Accounts Receivable and Accounts Payable module
      2. Every Transaction sent to Middleware was updated in log form
      3. This helped in the monitoring the transactions which were either successfully transferred or failed transactions
      4. For successful transfer of transactions, Middleware is acknowledging receipt of data.
      5. For transaction failing - Middleware is sharing the reasons for failure.
      6. For resending failed transaction - users could edit few fields like tax registration ID before attempting to resend the data.

   4. Developments with lead ERP

      1. Fields to setups classification for Vendors/Customers masters-eg Self Billing, E-Invoice, Exempt
      2. Government portal mandated fields - Tax Type, Classification codes,
      3. Fields on Transaction Screens for points mentioned above, logic default the values from the Vendors/Customer masters
      4. Validation messages to prevent posting of transactions with insufficient or incomplete information i.e. checking for information as required by Middleware and/or Government Portal.
      5. Transaction level logic - preventing transactions from rolling over to middleware if for e.g the IRB transaction ID is available for self-billed transactions
      6. Credit Notes/Reversals - program logic to cover following scenarios
         • Reversals need to be referenced to original transactions so the information required by Government portal can be copied/derived from original transactions.
         • Logic to handle reversals for transactions prior to 01 August’2025 are to be reversed.

Challenges

• Frequent changes in government guidelines/regulation
• Potential penalties for non-compliance
• Open Items which were not closed before securing sign off by stakeholders
• Potential Delays in receiving in API from Government Portal which in turn was impacting receiving API from