FloQast's AI Matching module allows teams to compare two sets of transactions to ensure month end balances tie out. FloQast API allows you to submit General Ledger (GL) or Subledger (SL) transactions to be utilzied within AI Matching.
The high-level flow of submitting GL or SL transactions is very similar. The same endpoint is used but the required and optional fields available when submitting data are different for each integration type.
Transaction data submission starts with getting a list of FloQast Reconciliations. This provides you with the required data to map accounts to your ERP or third party systems in Step 2 and submit data in Step 3.
When transactions are submitted to FloQast:
GL transactions must include FloQast Entity ID, month/year and the GL account as defined within FloQast.
SL transactions must include FloQast Reconciliation IDs.
- The Reconciliation ID for a given GL account is different for each period, so you must pull new IDs each month.
For a basic overview on what makes up a Reconciliation, see the Setting Up Reconciliations API guide.
See this guide for API Key creation.
Before proceeding, you must determine which Reconciliations in FloQast are included and update their settings to enable Matching. This also allows you to use the filter[autoRecType]=AI_MATCHING or [journalSource]=SUB_LEDGER filter to limit data to only these accounts.
- When submitting SL data you must also enable the Subledger Tie Out setting to accept SL API data.
GET Reconciliations /api/v1/reconciliations
Query parameters:
One of these is required:
filter[month]=MONTHandfilter[year]=YEARfilter[modifiedBefore]=YYYY-MM-DDfilter[modifiedSince]=YYYY-MM-DD
Recommended:
- GL or SL:
filter[autoRecType]=AI_MATCHING: limit API response to only Reconcilations set for AI Matching. - SL:
filter[journalSource]=SUB_LEDGER: limit API response to only Reconciliations of typeSUB_LEDGER
- GL or SL:
Optional:
filter[entityIds]=ENTITY_ID: limit API response to only a single entity.filter[workflowIds]=WORKFLOW_ID: limit API response to only a single workflow.filter[internalIds]=INTERNAL_ID: limit API response to specific gl internal IDs.- See documentation for more options.
Once a final list of Reconciliations and IDs has been compiled, it is time to fetch corresponding data from your source systems. Due to the number of different systems that exist, field names can differ significantly. A mapping exercise with the accounting team is highly recommended to ensure accounts and fields are mapped to FloQast properly.
As part of the initial GET Recs API response in Step 1, FloQast will return a gl object with several nested components that may be helpful for finding data in other systems. A particularly useful property may be gl.internalId which is often directly ties a ERP or third party system back to a GL account. Depending on your ERP, FloQast will also return additional metadata such as reportingBookId and subsidiaries wherever possible.
For each target Reconciliation, the source transaction data will need to be mapped to FloQast's GL or SL JSON schema. Both utilize the same endpoint, but the fields included differentiate the data submitted.
PUT Update Transactions /api/v2/transactions
- v2 endpoints should be utilized for all GL and SL integrations.
- The fields you choose to include in the
transactionsobject will be used to map data sources within AI Matching.- If you do not see a field name that matches what you are submitting, you must repurpose another field, which can then be renamed within the Matching module.
- You must send data through the available field name but the updated name in Matching will persist.
- If you do not see a field name that matches what you are submitting, you must repurpose another field, which can then be renamed within the Matching module.
- When omitting the
upsertvalue or includingupsert=false, a new API request to the samereconciliationIdoraccount,periodandentityIdwill overwrite the existing data FloQast has stored.- If data should be appended instead of overwritten, set
upsert=true. - Existing transaction IDs sent again will be updated, if there are any changes, and new transaction IDs will be added.
- If data should be appended instead of overwritten, set
- FloQast supports up to 2000 transactions per API request.
- If there is an account that exceeds 2000, make additional API requests with
upsert=true.
- If there is an account that exceeds 2000, make additional API requests with
GL: "ledgerType": "GENERAL_LEDGER"
- Required Fields:
account, ledgerType, period, entityId and transactions
{
"data": {
"account": "1000",
"ledgerType": "GENERAL_LEDGER",
"period": {
"month": "march",
"year": "2025"
},
"entityId": "5e94d5b63f557b001420bbe3",
"upsert": true,
"transactions": [
{ … }
]
}
}SL: "ledgerType": "SUB_LEDGER"
- Required Fields:
reconciliationId, ledgerType and transactions
{
"data": {
"reconciliationId": "5e94d5b63f557b001420bbe3",
"ledgerType": "SUB_LEDGER",
"upsert": true,
"transactions": [
{ … }
]
}
}Status ID: As part of GL and SL transaction submission, FloQast API will return a statusId.
- This can be used to call GET Status to check whether or not FloQast has successfully finished processing a given job.
- It is reccomended to add this as a validation step for your integration.
To validate whether transaction data was successfully submitted, a FloQast user will need to run the in-app Refresh process, triggered by clicking Refresh within the Matching module.
- If you do not see data populate on refresh, confirm the Reconcilaition and Matching settings are enabled to pull API transaction data.
As needed, a FloQast sandbox Entity can be created to begin sending data to those accounts before moving into production Entities. Please ask your setup lead for more information on creating Sandbox Entities.
Determine the frequency of data updates. This is highly dependent on each organization's business requirements. More frequent is not always better, and the best source of truth is the accounting team.