What file formats are supported?
AutoRec matching can support XLSX or CSV files.
What format should my dates be in?
AutoRec Matching can read any date which is in a cell formatted as a date in Microsoft Excel. As long as Excel says "Date", FloQast will be able to interpret that date in the system.
If you are unable to format a cell as a date type in Excel or are uploading a CSV file, your dates will need to be in a US date format that has day, month, and year listed in the text. If you are unable to change the format, we recommend changing the cell to an Excel date type, which FloQast will be able to read regardless of formatting.
How large can my Excel files be?
AutoRec Matching currently supports all of the Excel specifications for volume. Notably, we support up to 1 million transaction rows per source.
Disclaimer: for data sets in the tens of thousands, having hundreds of transactions with the exact same amount may reduce system performance if Ref 1s are not exact matches.
How does the system choose what matches to make?
The matching engine tries to find the best matches (those with the strongest similarity) first, starting with one-to-one matches followed by many-to-many. This means that all one-to-one matches identified will be taken first before any many-to-many ones are considered.
In the absence of a good one-to-one match, the engine may still identify a match where the dates are close (within about 12 days) and the amounts agree, even if the ref fields don’t match. This is because while the Ref fields have the strongest impact on the match probability, the dates also contribute. This allows for matches to be made even when the reference fields are not perfect.
How do Many-to-Many matches work?
The key fields the system considers for making many-to-many matches are the Ref1 and Date fields. In some cases large many-to-many matches, with fifty or more transactions may not be correctly identified. If a certain many-to-many match is not made, it could be because of one of the following reasons:
One of the transactions was put in a one-to-one match, so the group of transactions was not complete.
The useful information was in ref2 instead of ref1.
Some of the transactions in the group were more similar to one another than the rest, which resulted in multiple subgroups being identified instead of the correct group.
For example: A couple of transactions in the group were identical on date/ref1/ref2 but the rest were slightly different. The identical transactions would end up in their own group and may or may not have a corresponding match.
Some extraneous transactions were included in the group, causing the total amount to be different than the other side. This can happen if there are transactions with ref1 fields that look very similar and have close dates but belong to different matches.