Efficient Trade Credit Management



Introduction

‘Trade Credit’ is an arrangement between a buyer and a seller, allowing buyers to buy goods from their suppliers without having to make immediate cash payments. These purchases are made ‘on-account’ with deferred payment terms; most commonly used payment terms being Net 30 (payment within 30 days from the date of invoice), Net 45 (payment within 45 days from the date of invoice) and Net 60 (payment within 60 days from the date of invoice). Payment terms vary from industry to industry; for instance it is not uncommon to come across payment terms of Net 180 in a high-value, slow-moving goods market, such as the Jewellery industry.

Trade Credit is the lubricant that greases the gears of business-to-business transactions. Buyers use trade credit to improve their cash flows while sellers use trade credit to increase their sales. According to some estimates, in the US, about 97% of B2B transactions are made on credit.


Credit Management

Just as bankers evaluate the credit risk associated with their loan customers, credit managers in a business evaluate the credit risk associated with extending credit to their customers. The process and methodology that a trade credit manager employs to assess risk are similar to those that bankers use.

In a business, it is the duty of the Credit Manager to play the role of a watchdog by being the Credit Controller: typically, Sales teams are incentivized to increase sales at the cost of overlooking credit risk; Credit Managers need to strike the right balance between sales and credit risk. An inappropriately high credit limit can put accounts receivable at risk while an inappropriately low credit limit could result in a loss of business. Credit Managers use credit limit (and sometimes payment terms) as the lever to control credit risk and strike an optimal balance.

Credit Managers use sophisticated risk models customized to their industry and business; they use these models to quantify a customer’s credit worthiness; and depending on the credit worthiness, set credit limits and impose controls to limit credit exposure. Credit managers use different parameters in their risk models to ascertain credit worthiness, even though the parameters used, vary across industries, they generally fall into the following buckers: 

Financial Health

Income Statement, Balance Sheet and Cash Flow Statements are used to analyse financial health. Key financial ratios (some of them being industry specific) are used in the model as indicators of financial health.

Payment Behaviour

For existing customers, their past payment behaviour is used as an indicator of their future behaviour. KPIs such as Average Days Late (ADL) are used to quantify payment behaviour.

Operational Indicators

Some credit managers use in their models, some indicators about a business’ operations such as: Age of a business, length of relationship as a customer, number of employees, number of customers et al.

Environmental Factors

Sometimes, it is important to consider environmental factors such as the country of operation of the customer (factor in political and regulatory risk), region of operation (if it is prone to natural calamities) and other such factors that have a bearing on the customer’s ability to pay back.

3rd Party Assessment 

In addition, it is not uncommon for credit managers to rely on credit bureaus such as D&B, Experian, Equifax et al for an independent evaluation of the customer’s risk profile. 


A good risk model uses an optimal number of data points to quantify credit risk of a customer and the quantitative score computed by the model is used for decision making. Following activities are part of a typical credit decision making process:

  • Define a risk model
  • Collect customer-specific data
  • Quantify credit risk of each customer using the risk model
  • Classify customers based on credit risk score
  • Set credit limits on customers depending on the risk class of the customer
  • Impose credit control
  • Periodically review customer profiles
  • Periodically review and fine tune the risk model based on its performance

Figure 1: Credit Decision Making Process

Most of these activities (except for the first and the last two) are automatable to a large extent and a good software solution can help Credit Managers improve the efficiency of their decision making process through automation. 

At HighRadius Corporation, we have developed a suite of software tools called the ‘Credit Decision Accelerator’ to automate a large part of the decision making process, freeing up valuable time for the Credit Managers and Analysts, so they can focus on the risk model.

In a sequel to this post, I will discuss how automation can help improve efficiency of the credit decision making process.

About the Author:
Mahesh YellaiMahesh Yellai is Director of Product Management & Marketing at HighRadius Corporation. He specializes in Product Strategy, Product Definition, Product Marketing, Competitive Analysis and New Product Development.


For any questions or comments on this post, please email us at info@highradius.com

Challenges With Traditional A/R - Part 2

In my earlier post, I’ve discussed about various challenges faced by accounts receivables teams using traditional A/R system combined with manual processing to apply cash. This post talks about HighRadius’ ReceivablesRadius Cash Application Automation accelerator and how this helps in automating your cash application process.

Imagine a system which could pull remittance data and lockbox information from myriad of sources, which could understand different formats of data and normalize them into one format, which could integrate paper and electronic data into one single data flow, which could apply complex customer specific rules to produce outputs compatible to your existing A/R system, which could completely eliminate manual intervention while applying cash back to your A/R system. Now, imagine the system works for you as a service, which means no in-house development or infrastructure costs. Also imagine the system works seamlessly with your existing A/R system which means practically nothing to setup if you want to employ this new system. Yes, the system you are imaging is nothing but HighRadius’ ReceivablesRadius Cash Application Automation accelerator in the real world.

Following illustration explains how ReceivablesRadius Cash Application Automation solution fits into your existing A/R landscape without disrupting the setup. The solution can be conceived as a level of abstraction where it acts as single point source for all your remittance and payment confirmation inputs. Behind the scenes (actually, in the cloud), the solution performs all tasks required to aggregate data from various input sources in different formats, applies various pre-defined rules and transforms the data to one unified format which can be consumed by your A/R system to apply cash.

Cash Application Automation            
 Figure 1: A/R systems employing HR Cash Application accelerator

Let’s examine how ReceivablesRadius Cash Application Automation accelerator solves the challenges discussed in earlier post:

Hybrid Remittance Environment – Solved:

When you are dealing with cash application, you are essentially dealing with same data (remittances and payment confirmations). However, the data could be coming in different formats depending on how your customer wants to send it. The same data can be sent as an EDI, in the form of Excel or scanned copies of checks. As we discussed earlier, collecting all this data from different sources and entering into your A/R system is manual intensive process. ReceivablesRadius Cash Application Accelerator is equipped with robust data aggregation engine which can receive and digest data in multiple formats

Customer Specific Rules and Lower Hit Rates – Solved:

The distinguishing factor which makes ReceivablesRadius Cash Application Accelerator different from any other solution available in the space is the hit rate it promises. The solution is designed to employ business rules engine at the heart of it which could intelligently transform remittance data taking each customer into consideration.

Infrastructure Issues – Solved:

ReceivablesRadius Cash Application Accelerator is basically a service working out of cloud. The only installation or development on your system would be developing/enabling interfaces to consume the output files generated by the Accelerator. This requires minimal or no in-house technical expertise to work with the solution. Following are few advantages of adapting the solution in this context:

  • No local server installation
  • Pay- as- you- go model
  • Rapid scalability
  • System maintenance updates are included in the service; don’t have to bother about technical know-how.
  • Reduced implementation time frames.

In conclusion, I just wanted to discuss various challenges being faced in cash application process and possible solutions. In the times where we saw huge financial setbacks recently, adapting innovative solutions to reduce DSO and eliminate manual intervention is very much required for companies’ sustenance. Choosing the right solution is always a tough choice and I hope this post helps in taking that decision. I am going to discuss more technical details about the solution in my forthcoming posts. Stay Tuned!

About the Author:

Seshadri Sastry is java team lead currently leading the development efforts for On-Demand Cash App in HighRadius Technologies with solid business rules background using Drools and SAP NetWeaver BRM.

Challenges With Traditional A/R - Part 1

The single most important step in Accounts Receivables life cycle is to apply the cash you have been receiving accurately and efficiently.  Inaccurate cash postings will have direct impact on your liquid cash reserves, outstanding receipts, dispute management and above all, customer satisfaction. Even a very efficient accounting department can not apply the cash on the same day if they were to do it manually, as there are lots of challenges (which will be discussed later) and manual work is always error prone and time consuming. The more lag between payment receipt and cash application you have the more unaccounted money and the more mysteries to solve

As it may sound, the cash application problem is not trivial. It involves fair amount of intelligence to seamlessly orchestrate cash flow from customer’s bank accounts to properly apply them on open receivables. It involves aggregating data from lockboxes and/or direct payments, remittance advices from different sources, matching PO numbers in remittance advice to invoice numbers, transforming data coming from customers to the format acceptable to your system, reason code mappings in case of deductions, credit memo/debit memo matching, et cetera. Traditional A/R systems are not designed to handle all these scenarios. The maximum they could offer you is to identify invoice numbers being paid when there is an exact match with the remittance data and determine whether a cash discount is for the correct amount and within terms. However, over 75 percent of cash receipts may still end up with manual intervention because only few customers provide correct invoice numbers with their payments and on top of it, there are always invoice short pays to deal with. 

Figure 1 Traditional A/R systems combined with manual cash application

Figure 1Traditional A/R systems combined with manual cash application

Let’s examine few challenges with Traditional A/R systems combined with manual application in the following sections:

Hybrid Remittance Environment:

When you are dealing with multiple customers, there is a huge possibility that the remittance advices could come from a myriad of different sources in a variety of forms based on the software systems your customers using and payment methods they have chosen.  Collecting and deciphering data coming from different forms and sources is a huge manual task as your traditional A/R systems are not equipped to do that.  As a result, the cash application process involves significant manual processing with manual workflows and data entry thus reducing the efficiency and eventually increasing days sales outstanding for wrong reasons.

Lower Hit Rates:

As we discussed earlier, the traditional A/R systems could definitely apply cash to some extent. Typically, most cash receipts include some data that exactly matches open receivables without requiring any further processing. The remaining remittances, which are more difficult to match, involve some sort of intelligence to clear them off, like checking against credit memos, to see if discounts taken are as per terms in case of short payment or the verify against purchase order numbers, et cetera. What this means is even the A/R software is able to achieve a 65% hit rate, it would have just cleared the cream off the top and left the hardest tasks to be processed manually. The bulk of the remittances can be processed quickly, whether that is done manually or automatically. Whether it’s traditional bulky software or a specialised auto cash application product, if it is not processing more difficult and time consuming remittances, it’s not adding much value to your cash application process.  Bottom line is, if the software is not promising 100% hit rate, there is no point in using the software.

Customer Specific Rules:

As you grow with your customer base, the more complex and challenging your cash application process becomes. Different customers behave differently with their data and you might have to employ customer specific rules to transform data.  There are two options to deal with this situation using your traditional A/R systems, either asks your customers to change their behaviour so that it fits in your eco system or expand your system so that you handle the new behaviour in house. Obviously, you cannot ask your customer to change their behaviour because he might be dealing with multiple vendors and why would he incur IT costs just because he is doing business with you? So you left with expanding your accounting team to handle new customers. The third option could be employ a new system which could handle any new customer seamlessly within your eco system and transparent to your customer.

Infrastructure:

Last but not the least; infrastructure is a significant challenge when you are using traditional A/R systems combined with accounting teams to apply cash. By infrastructure, I just don’t mean hardware, but the costs incurred towards on-premise installations, ramping up for any system changes, implementing for new customers, expanding accounting teams to scale for larger customer base, et cetera.

All these challenges can be solved in much better and elegant fashion using few accelerators in tandem with your existing A/R system. In my next post, I will discuss how HighRadius’ ReceivablesRadius Cash Application Automation helps businesses significantly improve on-invoice hit rate by automatically matching open payments to invoices. How it solves hybrid remittance environment issues and above all how it employs intelligent rules engine to solve more and more complex customer specific and transformation rules to eliminate human intervention from your cash application process. I am also going to discuss how it is different from existing products in this space and offers more value to your business. Stay Tuned!

About the Author:
Seshadri Sastry is java team lead currently leading the development efforts for On-Demand Cash App in HighRadius Technologies with solid business rules background using Drools and SAP NetWeaver BRM

Can Agile Methodology co-exist with Enterprise Architecture?

Introduction

There has been a fair amount of debate in recent times about the marriage of Agile and Enterprise Architecture. More so, because both the topics have been gaining traction over the last couple of years and we are seeing increasing adoption of these by companies across the software development spectrum. The discussion ranges from questions like a) can both of them really co-exist in an enterprise or b) are there any commonalities at all between the two to worth a discussion. To set the perspective of this discussion, let us go through quick snapshots of what Agile and Enterprise Architecture are all about.

Agile

It’s about Agility – in managing the (changing) requirements, in developing and testing the product and in delivering the final product. The iterative and incremental nature of Agile is inherent and common-sensical. Without getting into the Agile Manifesto or the specific methodologies (Extreme Programming and Scrum being the popular ones), let’s just understand that Agile is about involving all the stakeholders all the way and delivering quality product increments in specific timeframes – so that the final product is never away from the “big-picture” envisioned. In simple words – “It’snot the big that eat the small but the fast that beat the slow”.

Agile Pic1

Enterprise Architecture

The understanding of the term Enterprise Architecture (EA) is ambiguous at best and differs based on how EA is viewed from the perspective of different stakeholders in an organization. Enterprise Architecture is more about organization-wide structures and processes (not just technical but business as well) and how they interact and integrate with each other. EA includes all the domains commonly classified in an organization – business, information, applications and technology. Enterprise Architects model through various artifacts the current architecture and future vision of an entire organization.  Among the popular EA frameworks are TOGAF and Zachman. More often than not, Enterprise Architecture is confused with Solution Architecture. A common analogy to differentiate the two is the case of city planners and building planners. While a building planner is concerned with architecting and raising a quality structure, a city planner needs to look at it at a scale of a city – which would include the buildings as well as planning a city around these buildings.

Agile Pic 2
Source: Wikipedia

The Real Debate

At their core, EA is about detailed study of an organization, evolving the architecture and envisioning the organization’s future in terms of architecture while Agile focuses on project delivery, though both work the iterative and incremental way in order to account for and address the shifting nature of business requirements.

Organizations adopting Agile typically have ‘Iteration Zero’ where the architectural strategy is laid out, with low-level design being part of every iteration. This is one of the places where the two – Agile and EA – can cross their paths. During Iteration Zero, the Agile team can be made aware of the EA goals, EA repositories, shared infrastructure – which could be the base from where the high-level architecture for Agile implementation can be derived at. This will prevent the Agile team from ending up creating vertical silos, creating individual applications, which though might be successful but pose serious challenges in integrating with the rest of the applications in the company’s portfolio and impede the future direction of the organization from both technical and business perspectives.

Again the EA governance can span across the entire iteration, where the Enterprise Architect can play the role of ‘architecture owner’ during software implementation and deployment. TOGAF, an EA framework, refers to a term called ‘transition architecture’ – a stepwise implementation of the target architecture – which is an apt place for Agile implementation. Another area where EA can learn from Agile is how the EA artifacts can be kept as simple and as concise as possible, so that these artifacts become useful to the Agile team as well and not too much effort is spent on creating costly artifacts, knowing these artifacts could become outdated by the time those are planned to be used.

Conclusion

Agile and EA differ on the scale of their respective operations. While Agile is at a Function/Process level (though Agile might have been adopted across Functional/Process levels in an organization), the level of Enterprise Architecture is rolled-up to an organization level. Also, while EA is a top-down approach, Agile is bottom-up. As it stands today, the adoption of the two will remain strong at their respective levels and the two will adapt principals from each other and leverage the best lessons from the other approach. Both Agile and EA can and should be adapted to fit organizational needs. As mentioned earlier, EA practitioners will benefit by working in an Agile way, by following principals that Agile Manifesto is based on. At the same time, Agile will gain by keeping the big-picture Enterprise Architecture in perspective during multiple iterations.
The clarity about co-existence of Agile methodologies and Enterprise Architecture sets in if both can be thought of working hand-in-hand in furthering the organization’s long-term objectives, with both being people-oriented, iterative, incremental and focusing on Business stakeholders.

About the Author:
Ujawal Sinha is a Principal Architect at HighRadius. He is with the Architecture team working on both SAP and JAVA technologies. He holds a  Bachelors degree form IIT, Kharagpur and a Master's degree from University of Southern Califonia, Los Angeles