Scroll for full TOC

User Guide

Practical guidance organized sequentially to help you meet requirements, monitor processing, and avoid rejections.

System of Record

During onboarding, you should have completed setup for your System of Record (SOR) to communicate with vExchange, using the approporiate business adapter(s) that you selected for your software and creditor(s). Confirm SOR setup is complete. If you still have additional setup, you can refer to the following information.

Collection-Master
Q-LawE & Q-Law
  • Instructions for the YGC Business Adapter are covered in YGC Setup.
Non-Vertican SOR
  • During onboarding, you chose an adapter: vExchange Native or the YGC Business Adapter.
  • If you require additional programming to your interface, you can engage Vertican Professional Services, if needed.

Before You Export

Types of Requirements

Before you export files from your system of record (SOR) and upload them to vExchange, make sure your files and records comply with all requirements per the sections covered below.

File vs Record Requirements

There is often overlap between what you might consider a File requirement versus a Record requirement.

  • If a Record requirement is not met, it means the Record will be rejected even if the File is accepted.
  • However, some File requirements cover how Records are formatted in the file.
  • The requirements below are categorized as File or Record requirements according to the kind of rejection generated if the requirement is not met.
  • In the case of File Rejections or Records Rejections, Vertican does not edit your data. Correct the issue at the source and resubmit the file under a new name.

File Requirements

Both Universal file requirements and Adapter-Specific file requirements are covered below.

  • Meet file requirements to avoid file rejections and other processing issues.
  • Learn what to do if a File is Rejected.

Universal

These are the universal file requirements set by vExchange that apply to all adapters.

Category Universal File Requirements
File Name
Unique File Name Every file must have a unique name. A file whose name or contents match a previously received file is treated as a duplicate and is not processed. When resubmitting a corrected file, give it a new name.
Underscore Separates Characters Between letters and numbers, only use an underscore to separate characters. A space, dash, or slash will automatically be replaced with an underscore (_). Underscores added by vExchange may cause confusion if you are searching for file name without underscores.
File Format
Plain Text Only Files must be delimited or fixed-width text per your adapter's layout.
UTF-8 Encoding Only Files in any other encoding are rejected.
Accepted File Extensions Files with blocked extensions are rejected. Common blocked formats are CSV, XLSX, PDF, and EXE. (GPG and PGP are also blocked except when using an encyrpted connection.) See a list of all Blocked File Extensions.
Zip File Accepted Zipped files are unzipped automatically, and each file inside is validated individually.
Encrypted Connections Only .GPG and .PGP are accepted. If your connection is set up for encryption, any file without one of these extensions is rejected as unencrypted.
Prevent Excel Data Conversion If you convert an Excel file to TXT, or you manually edit a file, Excel can automatically convert the data format, which can cause problems when you upload the data to vExchange. If Excel creates format variations, those variations create a mismatch between your data and that of your Forwarder/Sender. For example, Excel may delete leading zeros in your Creditor FileNo or truncate numeric data. See How to Prevent Microsoft Excel Automatic Data Conversion.
File Contents
Data Required The file must contain data. Empty (zero-byte) files and files containing only headers are rejected.
No Blank Lines or Hidden Characters No blank first line, no blank rows, and no hidden characters (whether leading or not).
No Extra Lines or Characters Both fixed-width and pipe-delimited formats do not accommodate extra lines or characters that are not part of the adapter layout.
Rows Must Match Record Layout Each row in the file must have the correct number of fields for its record type — with no added or dropped fields. Each record field within the file must match the header it corresponds to per your adapter’s layout.
File Delivery
Correct Upload Folder Deliver to the correct inbound (ToVertican) upload folder as assigned by your business adapter.

Adapter-Specific

These are the adapter-specific file requirements you must meet in addition to the universal file requirements above.

Category CMvX File Requirements
All Records
Starting and Ending Characters Each record (line) in the file must start with a # and end with a ##.
Specific Records
Record 241 In Record 241,the ACCR_INT_BEF field must contain a numeric value.
Category YGC File Requirements
File Format
YGC Format File must be in YGC format. Each line (number) in the file must start with the YGC record number (RECORD_CODE) and cannot start with a #. If a line in the file starts with a #, the error message will display the Line # and the message "Not valid record for YGC, the line starts with - #".
Total Line Length Each record must meet the size specified by the YGC Data Standard for that record type.
File Contents
Valid Date in Date Field The date field must be in the format CCYYMMDD and not contain any other data.
File Delivery
CA20 records should be in separate files to segment upload by FTP Folder. Here's what happens to CA20 Records.
All records in the file are for CA20 Forwarder File will be moved to the ToVertican/Midland folder if it's not already in that folder.
No records in the file are for CA20 Forwarder File will remain in the ToVertican folder.
There are records in the file for both CA20 Forwarder and other Senders. File will be moved to a “staging” folder. A File Rejection will be sent to the Receiver: "Your company submitted files with records for CA20 and other Senders. Please split the data and submit the files to the appropriate folders."
Category vExchange Native File Requirements
File Format
Record Header in File Record Header must be in the file.
## Required ## must be at the beginning and end of a record.
Pipe Delimiter Only Pipe (|) is the only accepted delimeter. Any other delimeter in position #2 is invalid and will cause the file to reject.
Header or Data Identification on Each Line Each record line in the file must be identified as either H (header) or D (data): #|H| or #|D|.
Valid Record Type ID Each record line in the file requires a valid record type ID.
No $ or N/A Neither $ or N/A can be present in file.
Forwarder ID in Header The forwarder_id must be present in the header.
Agent ID in Header The agent_id must be present in the header.

Record Requirements

Both Universal record requirements and Adapter-Specific record requirements are covered below.

  • Meet record requirements to avoid record rejections and other processing issues.
  • Records can be rejected even if the file in which they were delivered is accepted.
  • Learn what to do with Records Rejections.

Universal

These are the universal record requirements set by vExchange that apply to all adapters. 

Category Universal Record Requirements
The Four Keys
Three requirements are summarized below. For details, go to Universal Record Requirements - the Four Keys.
Valid Keys Every record must include a valid vExchange forwarder_id and agent_id. This means the Forwarder must be your client and in vExchange and the agent_id must be your firm ID.
Matching Keys Every record must identify its account. Include the account identifiers (sender_int_file and cred_fileno) so vExchange can match the record to the correct account. Records that can't be matched are rejected. All four keys must match the Forwarder Placement Record 1001, even if a key is blank. For example, if one of these keys is blank in the 1001, the 2001 should also be blank. In this situation, the keys match and are not considered 'missing'.
No Duplicate Keys There can be no duplicate keys or sets of keys.
Record Format & Data Values
Required Fields Not Blank Required fields must not be blank.
Valid Dates Date fields must contain valid dates.
Only Numeric Data in Numeric Fields Numeric and amount fields must contain numbers only. For example, "6 biweekly" in a payment-term field is rejected due to non-numeric characters.
Maximum Field Length Values must not exceed the field's maximum length.
Delimiter Character Never use the delimiter character inside a data value within your file. For example, a pipe ( | ) inside a name or address shifts every field after it in the file, so the header no longer corrresponds to the record data.
Rows Must Match Record Layout Each row in the file must have the correct number of fields for its record type — with no added or dropped fields. Each record field within the file must match the header it corresponds to per your adapter’s layout.
Other
No Duplicate Record No duplicate records within a file.
Records on Archived Claims Records on Archived Accounts are not prohibited, but are not passed to the Sender.

The “Four Keys” are unique identifiers that identify claims. Every record must identify its account. Include the account identifiers (sender_int_file and cred_fileno) so vExchange can match the record to the correct account. Records that can’t be matched are rejected. These identifiers are loaded into vExchange when a claim is established. To successfully update a claim, a record update transmitted through vExchange must match an existing set of these identifiers.

  • If no matching set is found, the record will be rejected since the Four Keys do not match.
  • All four keys must match the Forwarder Placement Record 1001, even if a key is blank.
    • For example, if one of these keys is blank in the 1001, the 2001 should also be blank. In this situation, the keys match and are not considered ‘missing’.
  • Individual records within a file (one or multiple records in a single file) will be rejected if one or more keys are either missing or do not match the Forwarder information. This is the error message:
    • Record does not match the 4 keys (cred_fileno, sender_int_file, forwarder_id, agent_id) as received in Forwarder Placement Record 1001**||**
  • Ensure there are no duplicate keys or sets of the Four Keys in your records as this will cause a Record Rejection.

Each key is listed in the left column, followed by its location within each product. All four keys must be present and match the Forwarder Placement Record 1001.

Key to Match vExchange Analytics Collection-Master Q-LawE YGC
cred_fileno Creditor Fileno MASTER.FORW_FILENO

Placement screen in the “File” field next to the Forwarder Number. 		debt.custfile

Workcase > enter ourfile > debt.custfile field identified in this screen. 		FORW_FILE
(Forwarder File Number)

Acct # issued by original creditor (aka Original Creditor's File #)
sender_int_file Sender Fileno MASTER.FORW_REFNO

Placement screen in the “Ref” field next to the “File” field that is next to the Forwarder Number. 		debt.ncustfile

Workcase > enter ourfile > debt.ncustfile field identified in this screen. 		FILENO
(File Number)

Internal file # of Sender placing the account (aka Sender's Internal File #)
forwarder_id Sender Id MASFORW.EDI_ACCT_NO

Inside the Forwarder file [1-2-1-1] EDI Setup screen that is the Account # for the Forwarder. 		cust.edicltcode and cust.yougotclm

Workcase > Clients > client list > select client > Misc Info tab to view the fields identified in this screen. 		FORW_ID
(Forwarder ID)

Vertican ID of Sender placing the account. Typically 2 digit state code + 1-3 digit #.
agent_id Receiver Id Pulls from YouveGotClaims ID# in [1-S-4-8] cust.edifirmcod

Workcase > Clients > client list > select client > Misc Info tab to view the field identified in this screen. 		FIRM_ID
(Firm ID)

Vertican ID of Receiver working the account. Typically 2 digit state code + 1-3 digit #.
Type of Mismatch Example Result of Mismatch
Wrong Forwarder ID Receiver enters the wrong Forwarder ID. Claim cannot be matched to an existing claim from the intended Forwarder.

The Forwarder will not receive the data in their daily delivery files since the 4 keys do not match what the Forwarder has established on vExchange.
Wrong Forwarder Sub ID Forwarder uses multiple Sub-Forwarder IDs to place a single claim with a Receiver.

Receiver uses the Forwarder ID without appending the correct, matching Sub ID, such as:

• TEST.123 vs TEST.987 		A different Sub Forwarder ID will initiate a new claim rather than send it to the correct claim of the Forwarder.

The Forwarder will not receive the data in their daily delivery files since the 4 keys do not match what the Forwarder has established on vExchange.
Blank Fields Creditor Fileno is entered but Sender Fileno is blank or vice versa. If a field is left blank, it will establish a new claim in vExchange rather than matching the existing claim.

The Forwarder will not receive the data in their daily delivery files since the 4 keys do not match what the Forwarder has established on vExchange.
Format Variations Account mismatches can occur if the firm exports and manually updates the data with typos. Or the data was auto-formatted by Excel or other software. Examples:

• Letter I is re-entered as the number 1.
• Letter O is re-entered as the number 0.
• Excel got rid of the leading zeros in a Creditor FileNo.
• Firm appended “et al” to the Creditor FileNo.
• Truncated data (1234-5678-9012-3456 vs 1234-5678-90).
• Masked data (1234-5678-xxxx or ****-5678-9012, etc.).

Note: You can prevent auto-formatting by Excel. Read How to Prevent Microsoft Excel Automatic Data Conversion for more information. 		All variations from an exact match will create a new claim.

The Forwarder will not receive the data in their daily delivery files since the 4 keys do not match what the Forwarder has established on vExchange.
Claim Recalled The Forwarder placed a claim with a Receiver, recalled it, and placed it with a different Receiver. If we have a recall code on the former account with another agent id, then the account was recalled from the firm. The firm should review their Notes under the account in Analytics for a recall claim vX Status Code.

Adapter-Specific

These are the adapter-specific record requirements you must meet in addition to the universal record requirements above.

Category CMvX Record Requirements
Onboarding
200 Series Record The CMvX 200 series record updates existing claims. You must correctly onboard a claim with a 500 series record that matches your Forwarder so that vExchange will have a claim for you to update. Otherwise, you will receive an "Account not in vExchange" error and you must complete CMvX Record 198 Reset Cache.
Match 4 Keys when Onboarding When you onboard a claim, make sure the keys match the Forwarder's data. If not, you will receive a 500 Series Record Rejected Error.
Generating a Record
Fields Required See the CMvX Fields Required to Generate a Record.
Record Format
Proper Record Format Make sure to follow the proper CMvX record format and do not have duplicate sets of the Four Keys. Such problems may cause a Record Rejection for "Line incorrectly formatted, will not be processed".
Category YGC Record Requirements
Data Value
Valid Data Values Date fields must use a valid value in the format CCYYMMDD.
Record Type
Valid Record Type / Number Make sure the Record Type or Record Number is supported by vExchange. Otherwise, you'll need to remove the record from the file and determine whether it's a valid YGC record type.
Duplicate
Duplicate Record Do not duplicate a previously sent record. If you do, you'll need to fix or remove the duplicate record.
There are no additional record requirements other than the Universal Record Requirements above.

Gate Requirements

  • Make sure your files comply with any Gates (business rules) that a Sender has implemented.
  • You can find general information in the Overview Guide section on Gates.
  • If any of your Senders subscribe to one or more Gates, you are notified by Vertican and/or your Sender.
  • Analytics has Gates Reports that track your Sender’s rules so you can ensure compliance.

Archived Claims

  • Sending a record on an archived claim (account) is not prohibited, but it will not be passed to the Sender.
  • Records on archived claims will not be displayed in Analytics.
    • However, you can use the Archive Activity Report to search across all archive and unarchive events.
    • Both Senders and Receivers can check the history of a given account or find all events over a given period.
  • You can find more details in the Overview Guide section on Archived Claims.

Export from SOR

You should export data from your System of Record daily and upload it to the Vertican FTP in a timely manner. If you miss the Daily Processing Schedule, your files will be processed during the next day’s run.

Upload & Download

Using the FTP

Segment by Adapter & Sender

It is crucial to segment your files according to the appropriate folder on the FTP for both upload and download. View the FTP Folders you should choose based on your Adapter and Sender.

Login Instructions
Select Business Adapter

After login, you will see folders for the business adapter(s) you are subscribed to. Choose one of the business adapter subfolders.

  • CMvX: for Collection-Master SOR
  • YGC: for Q-Law, Q-LawE, and non-Vertican SOR
  • vEx: for non-Vertican SOR
Select Subfolder

Now select another subfolder. The three below are the main ones, though there may be others present.

  • ToVertican: Used to upload files to vExchange for processing.
    • If you are doing business with CA20, you must place all files for CA20 in the “Midland” subfolder without exception.
  • FromVertican: Used to download files from Vertican to you.
    • Rejections: This folder contains any rejected files or returned records. This location should be monitored so that any rejections can be corrected and re-uploaded in a timely manner.
    • Reports: This folder contains any custom reports delivered to you.
  • Historical: Used as a data transfer folder. Files placed here will not be processed and Vertican does not receive a notification of their upload.

FTP Schedule

Please review the vExchange Daily Processing Schedule to ensure that files are submitted before the daily processing time in order to meet the deadline for same day processing.

  • If files are received after the daily processing has started, submitted and approved files will be processed in the next day’s processing run.
  • vExchange validates, processes, and delivers data 365 days a year 24/7.
  • Any scheduled maintenance will be communicated to clients in advance. On rare occasions, emergency maintenance must be performed and advanced notice cannot be provided. In these instances, validated files will be processed in the next available processing run.

After Submission

Once a file has been submitted to the FTP in the correct folder and in the correct format, it will be moved off of the FTP and moved into an internal location at Vertican for pre-validation evaluation.

After submitting files, monitor processing status by checking for email notifications and checking your Rejections folder in the FTP. There are three types of file processing notifications.

File Accepted

Once a file has successfully passed pre-validation, you will receive an email notification that the submitted file was accepted for processing.

From: donot_reply@vertican.com

Subject: vExchange File Validator Application 

File accepted for processing – [name of file].TXT
File accepted on – MM/DD/YYYY H:MM:SS AM/PM

Once accepted, the file will no longer be visible to you on your FTP, as the successfully pre-validated file has been moved into the processing queue within vExchange.

File Rejected

When your file is rejected, it will not be processed into vExchange.

  • On a daily basis, check for file rejections in the FromVertican/Rejections folder on the FTP.
  • Your Rejections folder will contain a Rejections Reasons file that will contain the lines that have an error.
  • Address the rejection reason listed in the [OriginalFileName]_Rejections_Reasons.txt file or listed in the File Rejections reports.
  • You will also receive an email about the file rejection, including the filename that was rejected.
  • Rejected files must be corrected, renamed, and re-uploaded to the correct FTP Folder for re-evaluation.
  • If you fail to rename the corrected file, it will be rejected again.

File Processed

Once a file has been processed, you will receive an email notification specifying the file(s) processed.

From: donot_reply@vertican.com

Subject: File(s) Processed by vExchange

Below is a list of file(s) processed by vExchange:

CA20_20260910211613323.txt
CA20_20260910220151920_1411.txt
Unarchive Accounts_091026.txt

After Processsing

vExchange Analytics

After files are processed, data is available in vExchange Analytics, which should be checked daily. Use this site for monitoring, troubleshooting, and decision-making on your accounts and portfolios.

If you do not have access to the vExchange Analytics website, contact your Firm Admin, who can follow instructions in the Analytics User Guide by clicking below.

Records Rejections

Record-level rejections are created when a file contains a record that is improperly formatted or is missing required fields. The file may be accepted for processing into vExchange, while the record is rejected.

Record rejections can also be caused by errors in the Four Keys – either invalid, mismatched, or duplicate keys.

  • Record Rejections are reported in a Rejected Records file or Data Issues report and are sent to your FTP in the FromVertican/Rejections folder, which should be reviewed daily.
    • If you are using the YGC or vExchange Native Business Adapter, record rejection files are appended with an “RR” suffix and are often segmented by Record Number.
  • All Record Rejections should be evaluated, corrected, and re-submitted for processing into vExchange.
    • If Record Rejections are not reviewed and corrected, this data will not be created in vExchange nor will it be forwarded to your client.

Gates Rejections & Exceptions

The next step of vExchange processing is an evaluation of the submitted data against any vExchange Gates that a client has activated. Gates are business rules defined by Senders to control data flow. After files are processed, make sure you monitor Gates Rejections & Exceptions regularly to ensure your submissions meet Sender requirements.

Based on the Gates evaluation, there are two outcomes for the Receiver’s files:

  • Gate Rejection –
    • Data is imported into vExchange but not passed to the Sender.
    • Both the Sender and Receiver are notified.
    • The Receiver must correct the file and re-submit it.
  • Gate Exception –
    • Data is imported into vExchange and passed to the Sender, but the data is flagged for review since it doesn’t meet requirements.
    • Reports are populated with the Exception for both Senders and Receivers.
      • Any data that has been marked by a Gate Exception should be reviewed to identify whether any changes need to be made to meet the requirements of the Sender.

Was this helpful?

Yes
No
Thanks for your feedback!
Help Center > Self-Help > vExchange > Documentation > User Guide