Integrations

How to use this guide

This guide is here in order to give you guidelines to make it easier to do the integration from a technical standpoint.

Questions to ask before you begin

Before you begin, you should ask a couple of questions in order to pick the integration that simplifies the integration. This can be especially important if you are trying to get started quickly versus having a more complex or expanded scope of integration done.

In general, you will want to assess:

• What are the business objectives?

You will typically want to make sure that it is clear what the business owners have asked to do. Typically this might be things in addition to existing workflows or functionality.

• Where is the System of Record supposed to be?

This will really determine the type of integration you want to aim for. Most of the time, receeve is managing the entire relationship, but the accounting system of record is elsewhere. This means you can use a simpler approach to the integration, but you will most-likely have a little bit of work if there are business objectives that need to be met. An example would be full account restructuring. Receeve can process those requests, but if another system needs to do the setup of the restructured accounts, then you would want to take the inputs from receeve in order to automate that process.

• What type of system(s) can send the data to receeve?

You will need to assess what systems you have in order to send the data to receeve, and at what points in time that data can be sent. NOTE: This point can be especially critical if you need receeve to act as a System of Record. If the system feeding data into receeve isn't capable of sending the individual transactional data around an account, then you should not plan on using that type of more complicated integration. Typically the system sending the data knows the outstanding balance, maybe a few data points around that, and then some type of CRM style data: names, addresses, etc.

• What is that existing system(s) capable of?

If you know that this system sending the data can't really interface via the API, you are entitled to use the files in order to integrate. It is also possible to start with the files, and eventually transistion. This may cover cases where a core system would be replace later on, but you need a way to be up and running more quickly with receeve.

• Do you need operational data back? Do you want any data back for another purpose (like a risk team or analysts)?

This question will give you a gauge for determining how much work you may need to do in order to leverage receeve's data core more efficiently. When you do not need data back, or you simply need data sent for analysis, then your work will be simplified. Because you can also use the data for operational purposes, you may need to assess if you need any extra work done in order to process the data from receeve in a more real-time manner, or if a simple queue and processing later would suffice.

• What kind of hierarchy do you need for your accounts?

Some organizations anchor an account around the consumer. Others around a master account, with the consumer(s) hanging below that. Even though it can be changed fairly simply, it's better to know what you would like to have here before you start. Some factors to consider are whether you have that single consumer or payor relationship, or perhaps multiple products inside of an account, or, possibly a more specific case, like creditors, where data should keep itself separated. This can also impact how data is accessed in the account manager, or how you bundle claims inside of a strategy. Whatever you choose as the anchor or parent at top will dictate how the information is linked.