Sending Subledger Data
Table of Contents
What is a Subledger?
A subledger is a detailed record that tracks a specific subset of financial transactions within an organization. While subledger data still feeds into the general ledger, the extra layer of organization allows for more detail and reporting in specialized areas.
Some common examples of subledgers are:
- Accounts Payable (AP) - money an organization owes
- Accounts Receivable (AR) - money owed to an organization
- Payroll - wages, taxes, benefits, and more
- Cash - bank accounts, receipts, disbursements, and more
An extra wrinkle is that subledger accounts can frequently live in an application outside of an ERP. This is a byproduct of subledger use case complexity. AP and AR can be so critical and confusing that some organizations may buy dedicated software to handle the process.
During the accounting close, subledger accounts still need to be reconciled. As a result, data needs to be extracted out of subledger source systems for comparison against the general ledger.
Subledger Technical Flow
FloQast can accept two types of subledger data - balances and transactions.
These two data objects are not dependent on each other. A user can submit a subledger balance without having backing transactions. A user can also submit subledger transactions in isolation of a balance. The most complete picture of a subledger, though, involves both balances and transactions.
The high-level flow of submitting balances and transactions are very similar and can both be represented with the same diagram.
Step 1: Getting FloQast Reconciliations
The subledger data submission process starts with getting a list of FloQast reconciliations for a variety of reasons. First, when data is eventually submitted back to FloQast, balances and transactions must be sent with a reconciliation ID. Second, FloQast reconciliations contain potentially useful metadata for future steps. Last, the reconciliation ID for a given account is different between each period. This is because balances and transactions are generally time-sensitive and ever-changing.
For a more basic overview on what makes up a reconciliation, see the Setting Up Reconciliations guide.
As part of the initial GET Reconciliations API request to retrieve FloQast reconciliations, several query parameters can be used:
- Recommended:
filter[month]=MONTHandfilter[year]=YEAR: limit API response to only reconciliations for the target period - Recommended:
filter[journalSource]=SUB_LEDGER: limit API response to only reconciliations of typeSUB_LEDGER - Optional:
filter[entityIds]=ENTITY_ID: limit API response to only a single entity - Optional:
filter[internalIds]=INTERNAL_ID: limit API response to a specific gl internal IDs
Step 2: Sourcing Subledger Data
Once a final list of target reconciliations has been created, it is time to fetch corresponding data from subledger source systems. These systems will vary from organization to organization and can even be more than one. For example, an organization may house AP data in Coupa, travel expense reimbursements in Navan, and Payroll in UKG.
As part of the initial 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 subledger source system back to an ERP account. Depending on your ERP, FloQast will also return additional metadata such as reportingBookId and subsidiaries wherever possible.
As always, communication with the accounting team is key to understanding what data makes up a given subledger account.
Step 3: Consolidating Subledger Data
For each target reconciliation, the subledger source data will need to be mapped to FloQast's subledger transaction schema.
Again, open and continuous communication with the accounting team is key here. Due to the number of different subledger systems that exist, field names can differ significantly. A mapping exercise on a sample data set with the accounting team is recommended to ensure fields are mapped to FloQast properly.
Step 4: Submitting Subledger Data to FloQast
To submit data back to FloQast, use the PUT Update Subledgers and/or the PUT Update Transactions endpoints. For each balance or set of transactions, there must be an associated reconciliation._id which was returned in Step 1.
A unique aspect of transaction submission is the upsert property. By default, a new API request to the same reconciliation._id will overwrite the existing data FloQast has stored. If data should be appended instead of overwritten, please set the upsert property value to true.
This is particularly important for accounts that have many transactions. Currently, FloQast supports up to 2000 transactions per API request. If there is an account that needs to exceed 2000, simply make additional API requests with upsert=true.
As part of balance and transaction submission, FloQast will also return a statusId. The statusId can be used in our GET Status endpoint to check whether or not FloQast has successfully finished a given processing job.
Step 5: Scheduling Submission Frequency
The very last step is to determine what frequency data needs to be updated. This is highly dependent on each organization's business requirements. More frequent is not always better and the best source of truth here is the accounting team.
In-App Testing
To validate whether subledger data was successfully submitted, a FloQast user will need to run the Recs Refresh process. This process can be triggered by clicking the red circled button. If a subledger balance was newly added or updated, the reconciled balance seen in blue will reflect the change.
The same process applies for transactions. However, the presence of transactions on a subledger reconciliation will also render an additional download icon seen in the blue rectangle above. This excel download will generate a file using the transactional detail sent via the API.