The key data objects that YayPay uses from your import files to reflect your AR situation in the platform is summarized below. 

This is to help your familiarization process of the data format and CSV file structures to prepare your AR data in 6 CSV files which YayPay requires the data to be represented in (See Article link at the bottom of this page).

In assessing and deciding on the approach and the state of your data in your ERP so as to bring the relevant AR data into YayPay, you should involve your technical team to help you in some of these ways:

• Map the appropriate source data from your ERP 
• Create the data extraction and/or translation processes from your ERP that will cover the data scope to help you with your Collection Process through YayPay
• Create the method to also transfer the extracted data to your FTP Server described separately (see Article link)

Organizing your Data and Import into YayPay 

Initial Load of Current and Historical AR Data

When you start using YayPay, you may want to see a mix of both current (i.e. all Open items) and some historical AR data for the Customers you are targeting your collection process for.

The initial load of current data refers to all Open AR-related data that ensures YayPay reflects the same total AR balance as if you were to run an Aging Report in your ERP Production system to compare.

Whether you bring current or history data, the data from your ERP should cover the following for YayPay:

• Customer
  • The Customer Master record maps to your Active Customers in your ERP, i.e. where there is an open balance in your ERP.  
  • Every Customer in YayPay has its own balance that will aggregate to form the Total Company AR (Total Due). Every other subsequent record for YayPay e.g. Invoices, Payments, Credits, etc are then associated with the Customer
  • If you maintain how each AR Specialist/Collector is associated to each Account/Customer in your ERP, this association can also be brought over
  • If your Customer representation in your ERP is differentiated into/by sites (e.g. "LCP Associates" is not a single customer, but you may have "LCP Associates (Bedford)" and "LCP Associates (Rockport)", you should consider this as 2 separate Customer records for YayPay especially if they have their own invoices/billed separately in your ERP
  • Parent/Child Relationships
    • A hierarchical structure is also supported for Customers for you to represent parent/child relationships in YayPay (e.g. you can enable the billing contacts of the Parent company to view a consolidated balance derived from the open items across all child companies, if you invoice and collect at the parent level)
    • Each Parent needs to be represented as a Customer record in itself, in addition to the child companies themselves as Customers also, referencing the Parent ID to establish the relationship
      
      Example  
      This is how a customer record from the customer.csv file appears in YayPay once the record is imported. The customer record will be shown on the Aging Report page and on the Statement page when you perform a Search action: 
       
• Contact 
  • Each Customer in YayPay can have a number of Contact records from your ERP
  • A Contact record consists of a First Name, Last Name, a Telephone No, an email address, etc. You should also decide if the contact is to label as a Billing or a Non-Billing Contact in YayPay. This example shows a Billing Contact created in YayPay for the Customer "Brinks", and the email address brought from your ERP: 
    
  • When these Customer Contacts are included as Recipients in your Workflow, the email addresses will be used by YayPay to send the Email Reminders via your AR Mailbox
    
    Example  
    This is how contacts from the contact.csv file (linked to a customer) appear in YayPay once the records are imported. Together with the customer record, the contacts will be shown on the Statement page:
     
• Invoice 
  • Your Invoice process in your ERP will record your billing for goods and services provided to your Customers
  • You should update YayPay when a new Invoice is created in your ERP (depending on the frequency of your billing cycle), or if the Invoice was changed/updated in your ERP (e.g. when the Invoice Amount was corrected because it was issued wrongly, or it has been fully paid or partially paid, etc)
  • In YayPay, Invoices are shown on the Statement page (under the Open Invoices tab and Closed invoices tab) as well as on the INVOICES menu/page
  • You may also see your Invoices having their status displayed in the Application user interface as "Partial" for partially paid (which are still Current Invoices) or "Paid" (shown under the Closed Invoices tab). These statuses are influenced by how your Invoice data is represented:
    • IF "paid" = 0 THEN the invoice is unpaid (shown as Current)
    • IF "paid" > 0 AND paid < "amount" THEN the invoice is partially paid (shown as Partial)
    • IF "paid" >= "amount" THEN the invoice is paid (however, consider if this is an overpayment and there might be a credit on the Customer/Account also)
      
      Example
      The following example illustrates how an open and closed (paid) invoice records are represented in the invoice.csv file. After the CSV import, these records will appear in the OPEN INVOICES and CLOSED INVOICES tabs on the Statement page:
       
• Invoice Lines 
  • An Invoice record can contain 1 or multiple invoice line items, which describe the item details of the Invoice
  • The line item represents individual goods or services that a buyer has purchased from you (or the item to be delivered). The sum of all line item Amounts should equate to the total Invoice Amount due for collection
    
     
• Transaction 
  • Different Transactions Types such as unapplied (Open) Payments, Open Credit Memos or Other open documents from your ERP that can impact the Customer's AR Balance
  • Credit Memo - If a Customer paid more than what was owed, or returned a product, etc, you may create an Open Credit Memo in your ERP to represent this activity/reduction. A Credit Memo is a Transaction type that can be brought over into YayPay. A Customer who has Open Credits imported into YayPay (i.e. On-Account Credits) can use this to offset an Invoice Payment when using YayPay for Payments )(See Article link). The Open Credit applied and Invoice may eventually close off in YayPay upon the next Sync/Import after the Invoice payment is applied/posted in the ERP
  • Payment - Payments imported into YayPay from your ERP represent Payments already applied or allocated, e.g. a single payment applied to 1 invoice or several Invoices, along with other information such as Payment Date, Payment Amount, etc.
  • Adjustments - represent an activity or changes to an invoice that in turn affects the Customer's AR e.g. a Journal Entry Adjustment Type may increment or decrement the balance
    
     
• Transaction Allocations 
  • Represents the relationship for each Type of Transaction - i.e. how the transaction is applied or consumed e.g. a single Payment is applied to 1 or more invoices, an unapplied Payment on the Account, etc
    
     

The Transaction and Transaction Allocations may not be a 1-1 mapping with your ERP, so it is best to also consult your Business users who are familiar with the data and scenarios in which these events may occur.

The overall relationship of the data from each CSV file mapped to how a user will see the information through YayPay post-import is summarized as follows:

1 – Data that comes from the customer.csv file.

2 – Data that comes from the invoice.csv and invoiceLines.csv files.

3 – Data that comes from the transaction.csv and transactionAllocations.csv files. 

4 – Data that comes from the contact.csv file.

Data in CSV files that Affect AR Balances

This section will explain the mapping between different CSV files and values in the YayPay user interface.

YayPay can calculate the customer balances based on the provided data. To achieve a correct calculation, the dataset provided to YayPay should be a full set of AR data that will allow YayPay to re-create the AR Balance of each customer as they are in the ERP system also. All Open Documents that impact the AR balance of each customer must be part of this AR data. Some examples of those documents are below:

• Unpaid or partially paid invoices that have an Open balance
• Open or Partial Credit Memos and unapplied Payments
• Any other Open Adjustments like Debit Memos, Journal Entries, etc.. (this may vary by ERP)

All of these open items should be represented and imported through the invoice.csv and transaction.csv files only. Information from the other CSV files is NOT used to calculate Customers’ balances in YayPay.

If you choose to enable YayPay to calculate a customer balance, the platform uses the following formula: Customer Balance = Sum of All Open Invoices Balances (invoice.csv) + Sum of All Open Transactions balances (transaction.csv)

Each invoice balance is calculated as a difference between the Amount and Paid field in the invoice.csv file.

Each transaction type balance is calculated as a difference between the Amount and AmountApplied fields in the transaction.csv file.

The data in the transactionAllocations.csv file is used to represent and show how a payment transaction was applied to 1 or multiple invoices (or how the payment was allocated as you translate the data from your ERP). 

• The information in this CSV file does not affect the Customer Balance calculation. If the information in the transactionAllocations.csv file does not match the information in the invoice.csv or transaction.csv file, information from the latter 2 files will prevail for balance calculation
• The data represented in the transactionAllocations.csv file is optional. However, if present, YayPay will display the info under the PAYMENTS tab of the customer to show the payment and how it was applied
• Depending on the transaction type you have chosen to represent in the CSV file, the information can appear under the Open Credits tab, Payments tab, or the Adjustment tab of the Statement page in YayPay

Note: Transactions can only be applied to invoices and not other transaction types. 

Aging Report

Statement Page 

Invoice Page 

CSV Field Mapping

Sometimes CSV that ERP generates has field names or data formats that are different from what YayPay can understand. Thus, additional configuration is available in YayPay to define field mappings and other configuration parameters of the CSV integrations. 

This configuration is represented as a JSON file with the following format:

CSV Field Mapping JSON

{"customerFieldsMapping":{
  "webAddress": "Company_URL"
},
  "contactFieldsMapping":
  {
    "yaypayFieldName1": "customerFieldName1",
    "yaypayFieldName2": "customerFieldName2",
    "yaypayFieldName3": "customerFieldName2"
  },
  "transactionFieldsMapping":{},
  "transactionAllocationsFieldsMapping":{},
  "invoiceFieldsMapping":{    
    "paid" : "",
    "terms" : "",
    "amount" : "",
    "dueDate" : "",
    "currency" : "",
    "entityId" : "",
    "invoiceId" : "",
    "customerId" : "",
    "dateCreated" : "",
    "invoiceNumber" : "",
    "discountDate":"",
    "discountAmount":""
  },
  "invoiceLinesFieldsMapping":{},
  "transactionTypeFieldMapping":{
    "CreditMemo": "CM,CreditMemo",
    "Payment": "PMNT,Payment,Check",
    "JournalEntry": "JE,Journal Entry",
    "Adjustment": "Adjustment,DebitMemo,Currency Revaluation"
  },
  "salesOrderFieldsMapping": {},
  "transactionDateFormat": "MM/dd/yyyy HH:mm:ss a",
  "transactionTimeZone": "-07:00",
  "invoiceDateFormat": "yyyy-MM-dd'T'HH:mm:ss",
  "invoiceTimeZone": "-07:00",
  "transactionAllocationsDateFormat": "MM/dd/yyyy HH:mm:ss a",
  "transactionAllocationsTimeZone": "-07:00",
  "salesOrderDateFormat": "yyyy-MM-dd'T'HH:mm:ss",
  "salesOrderTimeZone": "-07:00",
  "discountDateFormat" : "yyyy-MM-dd"
}

Now, let's unpack it one by one. Each mapping section of this configuration is associated with one specific CSV file. Sub-elements of the mapping define what field names in CSV files should be mapped to what field names in YayPay. 

For example, customerFieldsMapping.webAddress element in the example above, defines that the CSV column with the title Company_URL will be mapped to webAddress field in YayPay. Note, that all the names of the fields on the left should match exactly the column names in YayPay CSVs (see above). 

Now let's look at each configuration item separately:

Date and time-zone-related configuration fields allow YayPay to correctly read different date formats. 

Correctly defining a time zone is crucial for the system to work properly. If the time zone is not defined, by default, YayPay saves dates in the UTC time zone, and if your business operates in PST (UTC-7) time zone, this means your information will always be 7 hours behind, and sometimes even displayed as a different date. 

We have 3 files that expect to receive dates - transactions (transactionDateFormat, transactionTimeZone), invoices (invoiceDateFormat, invoiceTimeZone), transaction allocations (transactionAllocationsDateFormat, transactionAllocationsTimeZone). For each of them, we have a pair of elements - one for date format and one for time zone. 

We use the Java SimpleDateFormat format for both date and time zone.

Configuring CSV Mapping

You can find CSV Mapping configuration on the Integrations page (Settings → Integrations) in either CSV or FTP configuration, depending on what you are using.

(1) - Download an example mapping file, that you can use as a template to create your configuration

(2) - Upload file to the system after you completed it

(3) - Download current Mapping configuration

ERP Custom Fields

YayPay also allows for additional custom fields and values from your ERP which you may wish to import, display and use in YayPay. This is available at 2 Levels:

• Customer Level
• Invoice Level

Refer to this Article link on how to configure the name of your custom fields and display options in YayPay. This settings page works in tandem with the custom fields/values found in your customer and invoice.csv files.

Practical Note: If you replicate your customer id as another custom field column in the customer.csv file, you can use the Global Search menu in YayPay to search/lookup your Customers using the id.

Practical points on separating the Import of Production Data

During the final import of all Production data, we recommend that the current and historical data be split up into 2 separate zip files. 

This will also help users reconcile after the import of current data is completed (i.e. Total AR and/or customer balances should be the same as the snapshot taken from the ERP), followed by history data which typically represents "closed" information that will not influence the Total AR. 

While we recommend 1 year of historical data (i.e. closed invoices, historical payments, etc) for the purposes of forecasting payment timeliness in using YayPay, review this with your YayPay Representative if you require to bring in more.

Ongoing Import of AR Data (after a full Import of Production Data)

After the final import of all Production Data into YayPay, changes that are made in the ERP which continue to affect the total AR balance, etc also need to be sent to YayPay. 

We recommend that you update YayPay incrementally with changes on a daily basis or at a frequency agreed between the Busines/Technical team. These changes in the ERP to be sent to YayPay could include new information added recently, e.g. new customers, new/updated invoices, new payments, Invoices that are paid up, etc.

The import of this incremental data follows the same process - i.e. within the zip file that is loaded into YayPay, the same 6 csv files will be used and must be present within the zip file for ongoing import.

Invoice PDFs/Templates

In addition to your core AR data, you can also import your Invoice PDF/Template (as a PDF file) to display the document in YayPay. This process will happen after the CSV import is completed 

Refer to this Article link for more information

Once the Invoice Template/PDF is in YayPay, the document can be downloaded from the Customer Portal page, for the Finance Team to also view this through the internal Statement page, and/or also incorporated as a file attachment when you configure your Workflows / Email Reminders in YayPay.

Review AR Results/Outcome after Import 

As you start piloting and importing the key data objects outlined above, you will also start to see YayPay reflect your overall AR situation, e.g.:

• Use the Aging Report menu to view the overall Company AR and each Customer's balance (or use the Invoicesmenu to see a list of all Open Invoices, etc). If you use the Aging Report, click on the Export to Excel to also help you reconcile when required

• Both Current and Historical data per Customer will also be visible through the Statement Page and the Customer Portal page