A MAJOR-PROJECT REPORT

ON

“CLAIMS AND PROOF OF DELIVERY

AUTOMATION”
Submitted to
KIIT, deemed to be UNIVERSITY

In Partial Fulfilment of the Requirement for the Award of

DEGREE OF BACHELOR OF TECHNOLOGY IN

ELECTRONIC AND TELECOMMUNICATION
ENGINEERING

BY
MUKESH SHARMA
ROLL NUMBER: 1804244

UNDER THE GUIDANCE OF

HARSHIT AGARWAL

SCHOOL OF COMPUTER ENGINEERING

KALINGA INSTITUTE OF INDUSTRIAL TECHNOLOGY
DEEMED TO BE UNIVERSITY
BHUBANESWAR, ODISHA - 751024
2021-2022

1
 KALINGA INSTITUTE OF INDUSTRIAL
TECHNOLOGY
Deemed to be University
School of Computer
Engineering Bhubaneswar,
ODISHA 751024

CERTIFICATE
This is to certify that the project entitled
“Claims and Proof of Delivery Automation”
submitted by
MUKESH SHARMA (1804244),
is a record of bonafide work carried out by him, in the partial fulfilment of the
requirement for the award of Degree of Bachelor of Technology (Computer
Science & Engineering) at Kalinga Institute of Industrial Technology (Deemed to
be University) Bhubaneswar. This work was done during the year 2019-2020,
under our guidance. He worked with the team of CPA (Claims and POD
Automation) for HighRadius Technologies Private Limited, Bhubaneswar
during the Internship period at the company and sincerely completed all the
assigned tasks. The matter embodied in this project is original and has not been
submitted for the award of any other degree.

(Mr. Satya Teja Venkata Padmanabhuni)

(Principal Software Engineer – CPA)
(HighRadius Technologies)

(Prof. Meghana G Raj)

Project Guide

2
 Acknowledgements
I would like to take this opportunity to thank all my sources of aspiration during
the course of the internship.

First and foremost, I express my deepest gratitude towards my mentor at

Kalinga Institute of Industrial Technology, deemed to be University,
Bhubaneswar, Prof. Meghana G Raj for her valuable suggestions, insightful
criticisms, and directions throughout. I am grateful to Mr. Satya Teja Venkata
Padmanabhuni, Mr. Nilesh Kumar, Mr. Nikhil Kumar Sinha and Mr.
Harshit Agarwal, who gave an opportunity to work on projects at HighRadius
Technologies and for their continuous support during the internship and for
their patience, motivation and immense knowledge. They helped us and guided
us throughout the internship and development.

I am also thankful to my senior developers and team leads for their valuable
guidance, support, and cooperation extended by them. Then I would like to
thank my project team members for their kind cooperation, help and never-
ending support.

I am also thankful to KIIT Bhubaneswar for providing me technical skills and

facilities which proved to be very useful for our project.

MUKESH SHARMA
1804244
3
 ABSTRACT

Account receivables is one of the main challenges any business' operation.

Managing the deductions claimed by the customers has always been a major
challenge for any Business Organization. Companies receive thousands of
deductions every day. Aggregating claims and proofs of delivery for validation
from web portals or mails is a tough task. With poor management of claims
and deduction, not only company’s valuable time is wasted, but also the
efficiency and moral of the analyst and team goes down.
Applying payments to invoices accurately and properly identifying deductions
taken by customers is critical to audit performance and cash forecasting.
Inaccuracy in the cash application process can lead to slowdowns and
problems throughout the entire receivables lifecycle. Customer satisfaction is
enhanced by more accuracy in the way invoices, collections, and deductions
are handled.

HighRadius offers a Deduction Cloud which enables a proactive deduction

management operation which aims at streamlining the process, shortens
resolution cycle time, reduces processing costs and increase recovery rates on
invalid deduction. A very significant role of any Deduction Management
System is to capture deduction data from customers and supply the
information required for resolution. Backup documentation, such as Proofs of
Delivery (PODs) and Bills of Lading (BOLs) are captured automatically and
linked to the corresponding deductions to reduce manual research.

Thus, the main aim of this project was to collect and index claims from paper
submissions, email, EDI or customer websites and automate traversing
through other websites to retrieve backup documentation, for example PODs
and BOLs from carrier sites. This will help High Radius' clients to take better
and more informed decisions and optimize their deductions process.

Keywords: Account receivables, Payments, Claims, Deductions, Aggregation

4
Contents

Acknowledgement 3
Abstract 4
1. Introduction 7-10
1.1 Company Overview 7
1.2 Career at HighRadius 8
1.3 Account Receivables and Business Analytics 9-10
2. HighRadius Deductions Cloud 11-14
2.1 The Challenge 11
2.2 The Solution 12
2.3 How it Works 13
2.4 Deduction Management System 14
3. Terminologies and Technologies Involved 15-16
3.1 Basic Terminology 15
3.2 Claims & POD Aggregation in HighRadius Portal 17
4. Literature Survey 18-20
4.1 Phases of Implementation 18
4.2 HighRadius’ Roles and Responsibilities 20
5. Problem Definition 21
6. Requirement Gathering 22
7. Implementation 23–27
7.1 Tools used for Implementation 25
7.2 Development of the Agent 25-26
7.3 Unit Testing of the Agent 27
7.4 Testing by QA 27
8. Integration Testing Cycle and Deployment 28-30
9. Conclusion and Future Scope 31
References 32

5
List of Figures

Fig. 1 – Career at HighRadius 7

Fig. 2 – Account Receivables System Flow 9

Fig. 3 – Claims and POD Automation 11

Fig. 4 – Dispute Identification 13

Fig. 5 – Client and Customer 14

Fig. 6 – Claims and POD 15

Fig. 7 – Aggregation of Claims 16

Fig. 8 – Aggregation of Proofs of Delivery 16

Fig. 9 – Project Implementation 17

6
Chapter 1
Introduction

1.1. Company Overview

HighRadius is a Fintech enterprise Software-as-a-Service (SaaS) company that
provides an Integrated Receivables Platform to optimize receivables and
payments functions such as credit, collections, cash application, deductions, and
electronic billing and payment processing. The Integrated Receivables platform
allows suppliers to digitally connect with buyers via the RadiusOne network,
closing the loop from supplier receivable processes to buyer payable processes.
HighRadius solutions have a proven track record of reducing Days Sales
Outstanding (DSO) and bad debt, and increasing operation efficiency, enabling
companies to achieve an ROI in just a few months.
The goal is to help A/R and credit departments adopt innovative processes
supported by high levels of automation so they may become more strategic,
more streamlined, and more successful. It operates on three core principles: to
reduce the total cost of ownership (TCO) of receivables solutions, to deliver a
concrete return on investment (ROI) and fast payback periods to our customers,
and to provide innovative functionality to the market. HighRadius is trusted by
some of the world’s largest corporations and is consistently named one of the
fastest growing technology companies in Houston, where it is headquartered.
HighRadius offers two product lines as well as implementation services.
Receivables Cloud and Payments Cloud are SaaS-based solution suites that
automate and improve cash application, invoicing, and credit, collections, and
deductions management. HighRadius Accelerators are certified solutions for
SAP that enhance the automation available in the Receivables Management
modules and reside natively in the application.
Customer satisfaction is enhanced by more accuracy in the way invoices,
collections, and deductions are handled. These improvements all contribute to
the exceptional return on investment that our customers experience and the very
high level of repeat business they give us.

7
1.2. Career at HighRadius
HighRadius is an early-stage company providing software solutions for
automating a business’ order-to-cash cycle. For most businesses, accounts
receivable is either the largest or the second largest asset on their balance sheet
(in fact, it accounts for 40%, on average, of all the assets by value). Efficient
management of accounts receivable has a direct impact on the financial health
of a business. HighRadius is dedicated to helping businesses efficiently manage
this asset.
The products, uniquely complement traditional ERP systems and are delivered
both as a service over the web, deployed as software-as-a-service (SaaS) in the
cloud, and as add-ons to standard ERP functionality, deployed on-premises in
the business’ ERP landscape. Over the last few years, these innovative products
have gained significant traction in the market and the company is now in an
accelerated growth phase.
HighRadius seeks great minds, across different functions, to be a part of the
growth story. At HighRadius, you get:
● an opportunity to build innovative products that customers love
● a challenging work environment.

Fig.1: Career at HighRadius

8
1.3. Account Receivables and Business analytics
Accounts receivable is a legally enforceable claim for payment held by a
business for goods supplied and/or services rendered that customers/clients have
ordered but not paid for. These are generally in the form of invoices raised by a
business and delivered to the customer for payment within an agreed time frame.
Accounts receivable is shown in a balance sheet as an asset. It is one of a series
of accounting transactions dealing with the billing of a customer for goods and
services that the customer has ordered. These may be distinguished from notes
receivable, which are debts created through formal legal instruments called
promissory notes.
Business analytics is used to be the practice of iterative, methodical exploration
of an organizations data with emphasis on statistical analysis. It is used by
companies
with systematic data collection procedure to make data-driven decisions.
However,
over the last 15 years the business analytics field went through a great transition,
as
the amount of data available increased significantly. Specifically, this deluge of
data
calls for automated methods of data analysis, where researchers looked machine
for
help. Therefore, it is not surprising machine learning algorithm began to emerge
as a dominating force in the business analytics industry. According to Murphy,
machine learning is a set of methods that automatically detect patterns in data
and then use the uncovered data patterns to predict future data, or to perform
decision making under uncertainty based on knowledge from data.
Machine learning empower one's ability to transform the data into actionable
knowledge.
The transformational potential of predictive analytics are as follows:
● Creating transparency of business information
● Enabling experimentation to discover needs, expose variability, and
improve performance
● Segmenting populations to customize actions
● Replacing/supporting human decision making with automated algorithms
● Innovating new business models, products, and services
With these characteristics of business analytics, it is found a general pattern that
customers, consumers, and citizens benefit from the economic surplus enabled
by data they are both direct and indirect beneficiaries of big-data-related
innovation. It is also, worth noticing that some sectors are expected to enjoy
bigger gain when powering by business analytics. Because of the abundance of

9
data, computer and electronic product is no doubt the leading sector for its
strong productivity growth and potential gain from the use of business analytics.

Fig. 2: Account Receivables System Flow

10
Chapter 2
HighRadius Deductions Cloud

Claims and POD Automation empowers Deduction Management Software for

identifying and resolving invoice disputes and short payments to improve
profitability.

2.1. The Challenge

In Business to Business (B2B) scenarios, retrieving backup documentation for

deductions and collections is labor intensive and time consuming. Specialists
must manually find, retrieve, and print debit memos for hundreds or thousands
of deductions and then find the corresponding backup documentation, for
example Bills of Lading (BOL) or Proofs of Delivery (POD). This information
is pulled from external sources such as freight carrier websites one document at
a time.

Often, documents are lost and time is wasted requesting copies by mail or fax.
All of this inefficiency has a direct negative impact on Days Deductions
Outstanding (DDO) and Days Sales Outstanding (DSO) and consumes
significant analyst time which otherwise could be dedicated to identifying issues
and resolving disputes.

Companies receive thousands of deductions every day. And while most of them
are valid, deduction analysts still spend countless hours executing routine steps
to confirm deduction validity for each one.

Credit analysts perform credit reviews on blocked orders which for the most
part result in releasing the order in an unconfirmed expectation of future
payments.

11
2.2. The Solution

Proactive deduction management operation that recovers revenue normally

lost to invalid deductions

Claims & POD Automation is driven by a robust web aggregation engine that
identifies and captures the documentation needed for managing collections and
deductions. The solution collects and indexes claims from paper submissions,
email, EDI or customer websites and automatically traverses through other
websites to retrieve backup documentation, for example PODs and BOLs from
carrier sites. The documents are automatically matched and collated, making all
information required to research and resolve a dispute available in one place.
The captured documents are stored on the cloud in a searchable document
repository, making them easy to retrieve and integrate into collections and
deduction management workflows. The result is the near-complete elimination
of manual work involved in identifying, downloading, and attaching backup
documentation.

Corresponding trade promotions are also identified and suggested for settlement.
Workflow and automated correspondence engines streamline communication
and approval processes. The result is a proactive deduction management
operation that recovers revenue normally lost to invalid deductions.

Fig. 3: Claims and POD Automation

12
2.3. How it Works

Key features of Claims and POD Automation

● Data aggregation engine automates the monitoring of relevant websites,

email, EDI, and paper submissions to pull new backup documentation
such as debit memos, PODs, BOLs, etc.
● Auto-attachment matches backup documentation to the relevant
collections or deduction case.
● Document storage provides an image of the original document for
reference or disputes.
● Collation – We pick up all item levels of same invoice number and club
them together.
● Document Linking is done based on invoice number
● Document storage provides an image of the original document or
reference or disputes.
● HR portal-Client can download claims from every Customer portal just
by logging into HR portal.
● It provides a DM (debit memo) extract. All claims attachments along with
an index file for a day.
● For Deductions Management System, it converts all these claims into
pre- deductions.

Benefits

● Eliminate manual tasks that consume 20-40% of a specialist’s time,

allowing them to focus on higher value research and analysis.
● Reduce Days Deduction Outstanding (DDO) by speeding deduction
research and making backup documentation readily available for
settlement.
● Reduce Days Sales Outstanding (DSO) by speeding up payment.

13
2.4. Deduction Management System

Dispute Identification

HighRadius Deductions Cloud provides automation, process standardization,

and a platform for cross-departmental and customer collaboration. The solution
provides the most robust automation engine available to capture deduction data
from customers and supply the information required for resolution. Backup
documentation, such as Proofs of Delivery (PODs) and Bills of Lading (BOLs)
are captured automatically and linked to the corresponding deductions to reduce
manual research. Corresponding trade promotions are also identified and
suggested for settlement. Workflow and automated correspondence engines
streamline communication and approval processes. The result is a proactive
deduction management operation that recovers revenue normally lost to invalid
deductions.

Fig. 4: Dispute Identification

14
Chapter 3
Terminology and Technologies Involved
3.1. Basic Terminology

Client- Client or Account is the company that buys and uses our product.
Example- Hershey’s, P&G etc.

Customer- HighRadius Client's end-customers will be called customers.

Example- Walmart, K-mart etc.

Fig. 5: Client and Customer

Provider- The companies that provide service to the customer and data about
the customer’s transactions are service providers and data providers.

POD & BOL- Proof of delivery (POD) is a method to establish the fact that the
recipient received the contents sent by the sender.
A bill of lading is a document issued by a carrier (or his agent) to acknowledge
receipt of cargo for shipment.
These documents are mostly found on web portals.

15
Claims- When a customer pays less than the amount specified in the invoice
because of any related issue with the goods received. These are the documents
containing the list of items that they want a refund or rebate on.
The reason maybe delivering wrong product, damage or any other reason.
And these documents contain quantity, unit price and reference field for each
line item.
These can come in the form of Emails, Web portals, Image batches and EDIs
(812).

Claims Aggregation – Claim details and the claim documents from the select
customers shall be aggregated into the HighRadius portal.

Debit Memo Extract – Outbound extract with the claim details shall be sent to
the customer.

Payment- Money paid by Customer to Client for some product or service they
bought and got billed for. Payment can be in the form of: Checks, ACH or
Credit or Debit Card transactions.

Fig. 6 – Claims and POD

16
Chapter 4
Literature Survey

Claims from Customer Portals, E-mails and Third-party websites

Automate download and information capture for claim documents from emails,
paper claims, customer websites, and popular A/P networks and link these
documents to open deductions using robotic process automation.

PODs and BOLs from Carrier Portals and E-mails

Automate collection, information capture, and collation for PODs and BoLs
while linking them to corresponding open deductions.

Push Data to Customer Portals

Automatically post denial correspondence to the customer web portals for easier
notification and communication.

Fig. 9 – Project Implementation

18
4.1. Phases of Implementation

Phases Activities Prerequisite Objective

Preparation Review Client Contracts are Get good understanding of
Data signed customer as is process and
data to be prepared for the
blueprint phase.
Blueprint Design Preparation phase Conduct series of workshops
is complete to understand and document
As-is process
Develop future state design
and fit gap analysis
Realization Configuration, Process Design Develop functional
Build & Unit Document signed specifications for interfaces
Testing off and enhancements
Develop interfaces and
enhancements
Configure and unit test the
solution
Testing End-to-End Completion of all Perform end-to-end
Scenario build activities integration testing
Testing Fix bugs
Perform User Acceptance
Testing
Cut-over/ Go- Transition to Completion of Perform cut-over Activities
Live Production testing phase Training of end-users
Introduction to the ticketing
system
Hypercare Stabilization Go-Live 4 weeks of Consulting
Support to stabilize the
application

19
4.2. HighRadius’ Roles and Responsibilities

At a high-level, HRC will be responsible for all the implementation activities

within the solution from an implementation standpoint. Following is the
summary of these activities:

● Understand the client requirements and prepare the Process Design

Document (PDD) that will comprise of future state design for the
solution.

● Design interfaces for outbound data from the ERP system.

● Configure and build solution as per the PDD document.

● Unit test the solution.

● Develop integration test scripts.

● Conduct integration and User Acceptance Testing (UAT).

● Perform cutover task to move system into production.

20
Chapter 5
Problem Definition

The project scope is to implement the HighRadius Claims and POD Automation
module for customers to automate and optimize the claims aggregation. The
objective is to gather the claims data proactively and aggregate these
automatically. The customer will also receive these claims on a daily basis
along with an index file which contains the aggregated data at an item level.

The Process Definition Document aims to document the business processes

related to Claims automation for the customer. The PDD describes the Claims
automation process that the customer follows using HighRadius Claims module
and the method of extracting and transferring this claim information to the
customer. Furthermore, the PDD enumerates and explain the various design
decisions and field mappings for each customer.

Project Scope:
● Implement the following modules for Claims Automation
– Claims Aggregation
– Debit Memo Extract

Claims automation process retrieves documents such as customer Debit Memos

and Claims from various sources such as web portals, emails, EDI and OCR
debit memos without requiring any human intervention which significantly
improves the performance and accuracy.

All the claims that are aggregated will be sent to the customer. This is referred
to as the DM extract. The DM extract will consist of these claims in PDF
format along with an index file in XML format. The index file will contain all
the data aggregated at the item level for each claim.

21
Chapter 6
Requirement Gathering

• The consultants do research on the no. of customers the client has, the
volume of deductions to decide the top customers based on their volume
and the value of deductions, i.e., above or below a certain value they want
to consider. Eg: claims only above $30.
• They decide the no. of Agents – how many are out-of-the-box and how
many should be created
• The developers receive the validated Navigation document and field
mappings (which fields should be mapped to which columns)
• After receiving all information through the FS (Functional Specification)
sent by the consultant, the developer first manually navigates through the
web portal or e-mail inbox to understand the process clearly.
• Feasibility testing is done by the developer to understand and decide if
the development of the agent is possible or not.
• The claim documents or POD/BOL documents are fetched manually to
view and understand their format and feasibility for the agent.
• In case of claims, the documents are converted to HTML or Text format
to retrieve data from the document for aggregation in the portal.
• The development of the agent is begun by writing Java and XML codes
and preparing SQL queries.

22
Chapter 7
Implementation

HighRadius portal would be a one-stop solution to view Claims information

along with the related tracking information.

Customer’s claim or POD information will be aggregated from customer Web

portals. The aggregation process for the customers being automated is explained
below.

New Web Agent

The claims or PODs from customer are pulled using Web mode of aggregation.
The customer places a file containing a list of claim numbers or tracking
numbers in the customer’s SFTP server on a daily/weekly basis. This file may
be in csv format and contains claim number and vendor number with other
details about the claim. HighRadius uses this file to aggregate all the claim or
POD documents in this file from the customer’s website.

Alternatively, the customer places its claims directly in its web portal in
multiple pages which may or may not be able to be extracted to a csv file. In
such cases the agent has to navigate through the portal and through each page to
aggregate all claims or PODs for the given date range.

Enhancement in a Web Agent

There are many reasons an agent would require an enhancement. Some of the
reasons are changes in the customer’s website, changes in navigation,
modifications required in field mappings, new formats of documents, addition
of requirements from the same portal, etc. All the changes mentioned in the FS
are developed by the developer and assigned to QA for testing.

New Email Agent

23
The claims or PODs are available on the customer’s email portal, which are
forwarded to the email portal of HighRadius specific to an account. Different
customers have different labels in an email portal. For the development of an
email agent, it must first be known whether aggregation is required from the e-
mail subject, from the e-mail body or from the e-mail attachment. The agent is
developed to fetch attachments or email body data from the unread mails from a
particular label in the email portal. After downloading data and attachments,
another agent known as the Parser agent parses data from the email body or
from the attachment for aggregation.

Enhancement in an Email Agent

An email agent may require enhancements when there is requirement of change

in or additional field mappings by the customer, or when there are documents of
new format/s. The agent is enhanced to aggregate these new kinds of
attachments so that the automation process is not downgraded.

Bugs in Web/Email Agents

Bugs are raised by QA or by consultants when the agent does not function as
required by the customer. The developer has to find the issue in the agent and
resolve it for the proper functioning of the agent. It may be due to website issue,
changes in format of claim documents, mistakes by developer, etc.

24
7.1 Tools Used for the implementation
Operating System: Windows 10
Programming Language: Java 1.8,
XML
IDE Used: Eclipse Mars
Tools: Excel, SQLyog

7.2. Development of the Agent

In case of web claim agent, there are two types of agents involved – auto
agent and regular agent. The auto agent is configured to search claims in a
particular date range and aggregate those claims. The regular agent is
configured to search a particular claim based on claim number and
aggregate that claim only. The auto agent extends the regular agent. The
auto agent is developed to fetch the invoice numbers from the portal and
then the regular agent is called to process each claim based on the invoice
numbers sent by request attributes through the auto agent.

In case of web POD agent, there is only a regular agent involved, i.e., there
is no date range search through the agent in this case. The POD or BOL is
searched by the agent in the portal through a particular tracking number.

The agent is developed by referring to the navigation document to first

enter the web portal and perform each navigation one by one by providing
proper parameters and request headers till it reaches the page where the
claims or PODs/BOLs are present. Then the agent either exports all data to
a csv file or performs page-wise navigation for all the records.

Now that the agent has the invoice numbers, it performs regular agent
search for each invoice number. When the agent finds the particular claim,
it fetches and aggregates information about that claim from the portal
through regexes written in the agent. It then navigates into the claim to
fetch the required claim document. In case of POD agent, after the agent

25
finds the record for the particular tracking number, it further navigates to
fetch the POD or BOL document for that tracking number.

The document is aggregated for the particular claim number or tracking

number. For claims, information from inside the claim document may also
be required by the client. So, the agent is further developed to aggregate
header level data and item level data from the claim document. These
header level and item level field mappings are provided by the consultant.
This defines which field in the document should be aggregated as which
field in the HighRadius portal.

In case of email agent, there are two types of frameworks – old email agent
and new email agent. The old email framework consists of two agents – the
download agent and the parser agent. The download agent is a common
agent used by all email agents in the old framework to download
attachments and email body from the unread emails in the email portal for
a particular label. Parser agent is different for each provider. The parser
agent is developed to fetch data from the attachments or the email body and
aggregate the same.

The new email framework has 3 agents – download agent, qualifier agent
and parser agent. All these agents are common across all providers. This
email framework is developed only through queries and there is no need of
extra coding. Queries are raised in SQL to download attachments or email
body through the download agent, qualify those attachments or email
bodies through the qualifier agent and then parse the data through the
parser agent to aggregate data. The regexes for parsing of the data is also
given through queries which is stored in the database. The agent refers to
the database for its functioning.

The developer also enables the agent to create a Debit Memo extract or a
Tracking Information Extract if required by the customer. This extract
consists of the claims or PODs aggregated per day by the agent in a tabular
format.
26
7.3. Unit Testing of the Agent

After development of the agent, the developer does unit testing of the agent.
The agent is run multiple times to check its functionality across various
claims or PODs and across various formats. The developer checks whether
correct data has been aggregated into the database by the agent.

7.4. Testing by QA

● The QA team receives the functional specification document from the

consultant and understands the requirement of the customer from the
agent.

● The tester tests all the test cases mentioned in the FS across all the
accounts affected by that provider agent.

● The DM extract or TI extract is also validated by the QA and each

column is checked for proper massaging executed by the agent.

● In case of any issues the tester asks the developer to resolve it.

● When QA approves the agent, the agent is sent to production.

● Now the consultant can give the client a demo of how the agent functions.

27
Chapter 8
Integration Testing Cycle and Deployment

• Internal Testing is done by the consultant for all agents with the sample
extracts.
• Demo for the client is scheduled to ensure that all inbound and outbound
operations are intended.
• ITC Sign-off - Acceptance from the Client
• Migration of all queries and data to the production environment is done.
• Configuring Super Agents according to observed timeouts is done.
• Crons are configured to run the agent at specific intervals.
• Dry run on decided amount of data is performed.
• Once the output from Dry Run is accepted as intended, it can be moved to
Go Live.
• Hypercare
- Manual triggering for first few days.
- Testing with crons.
• Support
- Bug fixes are done.
- Agents are triggered if necessary.

Visibility of Claims and PODs in the HighRadius UI:

All claims aggregated by HRC will be available in the Claims module in HRC
UI. Only data that is directly extracted will be visible to the user. Any derived
fields are not directly visible in the UI. These fields are populated in the
outbound file to the client.
The client will be able to search for claims by customer name.
The client can also search for claims with other fields of the claim like Claim
Number or claim amount. Wildcard searches can be given for string-based fields.

28
Notifications to be sent to the customer

● All claims with a ‘success’ status type will be sent in the output file to the
client. The system will then try to re-aggregate all the other claims next day.
This will happen for 7 days (No. of days can be configured from 1 to 7). If
the system is unable to aggregate the claim after 7 days, it will be marked as
‘Failed’.

● A reconciliation report will be sent to the client every day.

● The system does not automatically send a list of failed claims but only gives
the number. Users should login to the UI and filter based on date and Status
to get the list of failed claims.

● Login failure notifications will also be sent to certain email addresses that
can be configured.

● The reconciliation email and login failure notification email should be sent to
the client’s email.

OutBound Extracts

Outbound Extracts are the files sent from HighRadius to the client. Claim
Extracts are files that contain the extracted information of all the Claims records
that are aggregated successfully by HighRadius.

The extracted files will be pushed to the client’s FTP server.

SHARP Interfaces

● HRC will provide Customer Invoice (Claim) File on a daily basis. The
transmission will contain the following:

29
o One zip file containing all the claim documents and any associated
supporting documents such as deal sheet that are available and
linked to the claim/customer invoice. The zip file will also contain
one XML file that has the indexed header and line level data for
each of the customer invoice copies or other supporting documents
with reference to the invoice copy or other supporting documents.

30
Chapter 9
Conclusion and Future Scope

● An automated deduction process goes through the same procedure as the

manual deduction system but is able to aggregate claims and PODs at a
much faster speed. As the CPA process has grown more and more
complex, many companies have moved to an automated process thereby
reducing the staff work load, cost and work burnout.

● Speed-up deduction resolution is possible with customizable workflows

for research and approvals with internal and external stakeholders across
A/R, sales, customer service, and broker teams.

● As the Claims and POD Automation develops, it will eliminate most of

the work of valuable human resources at the Client’s end, avoiding errors,
freeing up resources, and reducing costs. With the right technology in
place, businesses can resolve any challenges they face in their time-
sensitive deductions process.

● In the entire Order to Cash flow, business processes can be extremely

simplified by using such automated systems in place of valuable human
resources for more innovative and useful purposes. Not only the Claims
and POD Automation system, but also other manual systems in place,
such as Cash Application management, Credit management, Invoice
presentment and payment, Collections management as well as the
Discounts and Dispute settlement systems can be highly automated and
synchronized with each other to deliver a complete solution for managing
the Cash flow in the Accounts Receivables section of the Financial
Supply Chain Management (FSCM) for every business.

31
References

www.highradius.com - For all the information about the company

https://www.highradius.com/uk/integrated-receivables-
solutions/cloud/deductions-cloud/ - For information about HighRadius'
Deductions Platform

https://www.highradius.com/integrated-receivables-
solutions/receivablesradius/pod-claims-automation/ - For information about
HighRadius’ Claims and POD Automation system

M. He, C. Ren, B. Shao, Q. Wang and J. Dong, "Financial supply chain

management," Proceedings of 2010 IEEE International Conference on Service
Operations and Logistics, and Informatics, Qingdao, Shandong, 2010, pp. 70-
75.

32