General Ledger Integration

Direct integration of LeaseAccelerator with the general ledger eliminates the need for manual extraction and upload of the debits and credits from the leasing subledger. Direct integration ensures that the general ledger is kept in sync, minimizing the risk of journal entries being unintentionally excluded from reporting results.

Download a PDF version of the Enterprise Integration User Guide.

Business architecture

LeaseAccelerator is the subledger for your lease accounting. To support the monthly close, a consolidated set of journal entries from the leasing subledger (LeaseAccelerator) must be posted into the ERP general ledger.

LeaseAccelerator maintains all information about your leasing contracts (sometimes named schedules or deals) including all necessary asset lease details, accounting information, accounting classification, payment schedule, end-of-term actions, and lessors’ information.

LeaseAccelerator users can define as many ledgers (sets of books) as needed. Each ledger can support up to 11 segments (dimensions such as business units, cost centers, profit centers, etc.). to match ERP set(s) of books. (Please refer to LeaseAccelerator configuration and usage guides for details).

When lease contracts (schedules / deals) are booked into LeaseAccelerator, users link each deal to one or more ledgers. Based on this information, LeaseAccelerator generates the general journal entries (named as ledger entries) that must be posted to the ERP general ledger module. For each journal entry, LeaseAccelerator transfers details such as account number, account name, transaction amount, ledger date, segments, transactional currency, and debit or credit designation.

LeaseAccelerator generates ledger entries in transactional currencies. Ledger entries include “FX Conversion Date,” “FX Rate Type,” and “Currency,” so when posted in the ERP, the General Ledger module can apply the proper conversion rate for the transaction currency at the specified conversion date.

LeaseAccelerator also provides different “Key identifiers” for each entry line or group. Once ledger entries are successfully posted into the ERP General Ledger module, posting acknowledgment must be sent back to LeaseAccelerator using the key identifiers so that LeaseAccelerator can mark these entries as “Posted” as explained in detail below.

LeaseAccelerator can interact with multiple general ledgers running on different ERP instances from different vendors, including a mix of SAP, Oracle, and other applications.

Pre-posting and post-review good practice

The ledger export report can be generated manually whenever needed and can also be scheduled to be automatically generated and sent by email in a chosen format at specific days (relative to the fiscal period start and end dates).

It is a good practice to apply the following processes:

• Close the fiscal period in LeaseAccelerator.

• Once closed (at least 2 days before the planned integration day where ledger entries shall be sent to the ERP GL for integration), generate ledger export (can be scheduled or manually through the UI) and send it by email for revision by the lease accountant.

• The accountant will have two days to review and, if necessary, re-open the period in LeaseAccelerator and make any corrections needed then re-close the period.

• On the specified day, the integration officer will execute the integration and post entries into the ERP GL.

• The integration officer shall extract the ERP posting reference IDs (PostingId, PostingEntryId and LedgerEntryLineId) and complete the posting acknowledgment roundtrip back to LeaseAccelerator and acknowledge the functional users.

• The user shall manually generate the Ledger Export report again and choose to exclude all “Posted” entries, this would be an exception report showing all non-posted entries. The report should come up empty.

General rules:

• Only generate Ledger entries when the fiscal period in LeaseAccelerator is closed. If a user generates a ledger export file while the fiscal period is open, another user may change or add data to lease contracts that may trigger LeaseAccelerator to generate different sets of ledger entries.

• Once ledger entries are generated, the period should remain closed until the posting acknowledgment roundtrip is completed. Unless the generated file is trashed and not posted into the ERP GL.

Integration process flow

Typically, immediately after closing the fiscal period in LeaseAccelerator and before month-end closing in the ERP’s General Ledger, leasing journal entries need to be transferred from LeaseAccelerator to the general ledger where they should be posted.

P100: Start

The general ledger integration process must be triggered immediately before month-end closing in the ERP and must be executed for each ledger. The client executes the process for the primary and the secondary ledgers.

The fiscal month in LeaseAccelerator must be closed first to prevent any amendments or changes to LeaseAccelerator before posting the entries into the ERP and sending back the posting acknowledgment to LeaseAccelerator.

P200: Generate & transfer ledger entries

LeaseAccelerator provides a detailed ledger export report that shows the entries that will be sent to the general ledger. Regardless of the integration method selected, it is advised that accounting users should generate this report and review these entries before executing the integration.

Each set of books requires a separate general ledger integration exchange.

LeaseAccelerator initially marks the ledger entries as “New”. And, by default, the report shows entries marked as “New” or “Transferred” only.

Users can define a specific schedule whereby LeaseAccelerator automatically generates and sends the report in the specified format to designate users either by email or by SFTP to a specific destination.

Users can activate GL-C1 integration connection to transfer the entries as follows:

Upon successful transfer, LeaseAccelerator changes the status of the transferred ledger entries within the LeaseAccelerator internal database from “New” to “Transferred”.

LeaseAccelerator stores the transmitted ledger entries with posting referenceIDs, time/date of request, request parameters, and user requesting the transfer.

P300: Receive entries (GL-C1)

The ERP receives the ledger entries from LeaseAccelerator depending on the integration method as follows:

P400: Validated?

The ERP integration officer runs tools to validate the entries in the ledger export file.

The validation tools may discover two types of errors that will prevent posting these entries into the ERP general ledger as follows:

• Soft errors such as ledger codes, currency code, or accounts are invalid, or a null value was received for a non-null field.

• Hard errors, which usually result from file corruption due to transmission or disk I/O errors.

If an invalid ledger coding (either segment value or combination of segment values) is detected, the entire batch should be rejected and remanded to accounting for correction. Partial ingest is not recommended.

If there are errors, proceed back to step P200.

P500: Post to general ledger

Once the ledger entries file is validated, the ERP technical integration officer posts the ledger entries into the general ledger and records the success process in the integration log. The ERP generates a posting ID for each entry posted.

P600: Generate & send acknowledgement to LeaseAccelerator (GL-C2)

Journal entries that have been accepted into the general ledger are posted and should not be re-sent by LeaseAccelerator. The general ledger needs to advise LeaseAccelerator of these posted journal entries.

P700: Receive ack change status to “posted” (GL-C2)

For each referenced LeaseAccelerator journal posting reference ID, LeaseAccelerator marks the associated ledger entries as “Posted” and tags them with the posting IDs from the ERP.

LeaseAccelerator sends an email notification to the designated recipients that the file has been successfully received and processed.

The process ends here.

P800: Apply corrections

Depending on the errors detected, users would take necessary actions to correct those errors and regenerate the file.

Once corrections have been made per step P200, users should re-close the fiscal period in LeaseAccelerator then regenerate the ledger export file.

This time, the user must choose entries marked as “New” and “Transferred” since the transferred entries were rejected.

Understanding Posting Acknowledgement

LeaseAccelerator should be acknowledged about the ledger entries which have been successfully posted in the ERP General Ledger so that LeaseAccelerator would:

1. Exclude posted entries from successive ledger exports for the same period, preventing exporting duplicate entries to the ERP.

2. Lock the posted entries so that if the fiscal period was reopened and users applied changes to schedules that require the accounting engine to change the ledger entries, LeaseAccelerator accounting engine would generate new incremental and reverse entries without doing any changes to these locked (posted) entries.

LeaseAccelerator expects to receive acknowledgment file to be sent back carrying a list of 2 fields:

1. Reference IDs: LeaseAccelerator accepts any of the abovementioned keys (PostingId, PostingEntryId or LedgerEntryLineId)

2. External Document ID: Any text (cannot be empty) that should include posting reference in the ERP GL to enable cross-system tracing.

You can send back LedgerEntryLineId(s) or the PostingEntryId(s) or the PostingId(s) as the reference key to LeaseAccelerator to acknowledge posting of the corresponding entries.

Using LEDGERENTRYLINEID vs. POSTINGID vs. POSTINGENTRYID

LeaseAccelerator generates ledger entries, and these entries should be posted in the ERP General Ledger module.

To maintain synchronization between LeaseAccelerator and the ERP and prevent LeaseAccelerator from changing or deleting entries that were already posted in the ERP GL, LeaseAccelerator needs a “return receipt” or “Posting Acknowledgment”.

To enable this posting acknowledgment LeaseAccelerator Ledger entries, include one of three different key identifiers: LedgerEntryLineId, PostingEntryId and PostingId.

LeaseAccelerator also provides a field dedicated to store the ERP posting reference key “External_Document_Id”

Also, each line in the ledger entries file has a “Status” that LeaseAccelerator will change as follows:

• Newly generated entry lines will have Status = “New”

• Once entries are successfully pulled by an API or pushed to an FTP folder, the status changes to “Transferred”.

• Upon receiving the posting acknowledgments, which consists of 2 columns:

  • LeaseAccelerator posting identifier (which can be LedgerEntryLineId, PostingEntryId or PostingId)

  • The ERP posting reference key or any identifier to cross reference LeaseAccelerator with the ERP.

• The corresponding entry lines are updated so that the field “External_Document_Id” will contain the ERP posting reference key, and the Status is changed to “Posted.”

Once an entry line status is “POSTED,” LeaseAccelerator will never change or delete it, and if a change in the originating lease contract /schedule results in different ledger entries, LeaseAccelerator will generate incremental entries or delta entries as necessary but will never touch the posted entries.

LeaseAccelerator will “feel free” to delete and replace any entries that are not marked as “POSTED”.

To compare using posting keys, assume your lease portfolio includes 1000 lease schedules and each lease will generate 10 lines of ledger entries. Hence the ledger entries for September 2019 will result in 10,000 lines.

LedgerEntryLineId:

• Takes the format of LLXXXXXX where XXXXXX is an integer (up to 22 characters in size)

• Unique for every line of ledger entry within the same ledger. (In the above example, you will have 10,000 lines with 10,000 different LedgerEntryLineIds).

• “Static” Once created does not change and is not affected by period closing or reopening.

• Shows in all reports once a schedule is booked regardless of the fiscal period status in LeaseAccelerator.

• The key changes with each Ledger Export generated.

The scenario for using LedgerEntryLineId:

When comparing the two posting keys, the client found out that using PostingId and splitting the file based on this key will result in 1,000 journal vouchers to be posted into the ERP GL (each will have 10 lines). The client wants to have a limited number of entries posted to their ERP GL so they decided to use the LedgerEntryLineId and include each 500 entry lines into one JV (entry to the ERP GL). And add a manual entry line to balance the journal as they are not necessarily balanced (line 501).

Pros:

• The client ended up having 20 Journal vouchers only (of 501 lines each)

Cons:

• The posting acknowledgment must be sent back for each line, so the posting acknowledgment file for LeaseAccelerator will contain 10,000 lines (each line carrying a different LedgerEntryLineId).

• Each line is either debit or credit. This means that any mistake in sending back these IDs may lead to unbalanced ledger entries in LeaseAccelerator. LeaseAccelerator has no way to control this as it is changing the status to ‘Posted’ on a line-by-line basis.

• Ledger Entries can be extracted anytime (even if the period in LeaseAccelerator is open) so nothing guarantees that users may log into LeaseAccelerator and change data while the posting roundtrip is not completed yet.

• The client had to create a fictitious entry line (line 501) in each JV to balance each batch.

• The client must apply strict manual policy / control to prevent any changes in LeaseAccelerator during the period where ledger entries are extracted until the posting acknowledgment is completed. Otherwise, the client may end up with two different versions of ledger entries; the one that was extracted and posted in LeaseAccelerator and another that was generated based on the changes that were applied to the LeaseAccelerator deals.

• The posting acknowledgment may fail if some of the lines that was extracted were deleted by LeaseAccelerator because a user applied changes to the corresponding schedule in LeaseAccelerator and the status of the entries were still not posted because the posting acknowledgment roundtrip was not completed yet. And this may cause LeaseAccelerator Posted entries to go out of balance.

PostingId:

• Takes the format of “LX”+99999 ( up to 25 in size).

• Includes the “Period closing event number.”

• Is populated only when the fiscal period in LeaseAccelerator is closed.

• Every lease schedule will have at least one PostingId. If there are multiple Ledger dates or multiple currencies with the same schedules, there will be multiple PostingIds for the same schedule.

• Each PostingId will be shared among a set of balanced entries having the same ledger date and the same currency.

• The same PostingId (accordingly) marks a balanced entry.

• If the period is re-opened, the key will disappear from extracted files (except for the posted entries).

• When the period is re-closed, all lines will have new PostingIds (with the new period close event embedded). (Except for the entries already marked as posted).

• The fiscal period closing sequence is embedded into the PostingId key identifier. Hence every time the fiscal period is re-opened and closed, the PostingId will change. If a user tries to complete the posting acknowledgment roundtrip using key identifiers that was generated in older closing, it will be rejected.

The scenario for using PostingId

When comparing the two posting keys, the client decided to use the PostingID. Since SAP has a limitation of 999 entries per JV, the client decided to split the file to have one JV for every lease schedule (assuming the entries have the same ledger date and the same currency), resulting in 1000 JVs to be posted into the ERP GL.

Pros:

• Provides better control because:

  • This key will only be populated when the period in LeaseAccelerator is closed.

  • If the period is re-opened, the PostingIds will be wiped, meaning that if a user tries to do the posting acknowledgment for an open period it will fail.

  • If the period is re-closed again, all (non-posted) ledger entries will have new PostingIds. So, if a user tries to do the roundtrip using an older version of ledger entries, it will fail as LeaseAccelerator will detect that the incoming PostingId are obsolete (refer to an older period close event).

• The posting acknowledgment file will only include 1,000 lines. Each line will have the PostingId for a complete balanced set of ledger entries representing one schedule. So even if an error occurs during posting acknowledgment (missing records for example), it will never cause LeaseAccelerator entries to go out of balance.

Cons:

• Posting to the ERP can only start when the period in LeaseAccelerator is closed.

• The number of entries to the GL ERP is higher than the ones created using LedgerEntryLineId (unless the client pack – let us say – every 10 leases in one JV)

• May constitute a risk that a large lease contract with a huge number of assets may result in very large entries that may exceed 999 lines).

PostingEntryId:

• Takes the format of “LP”+99999 ( up to 25 in size).

• Works the same as PostingId above with the exception of how the PostingEntryId is assigned.  In the past entries marked with the same PostingId can have thousands of rows due to adjusting entries.  PostingEntryId will group rows based on the adjustment date. 

• In a PostingId there are non-adjusting entries and adjusting entries.  For PostingEntryId, there will only be one or the other and all rows with the same PostingEntryId will have the same adjustment date.

• This allows for smaller entries.

Integration process

Main use cases:

Common steps – with example:

1. The user closes the period in LeaseAccelerator.

2. The user generates a ledger export file from LeaseAccelerator or calls its API to generate ledger entries.

3. Integration engineers will run programs to convert them into ERP specific GL entries import document carrying the PostingId (in a proper field). Also assign a “source subledger” combined with “batch number” to all the entries (for example LA_LE_YYYYMM).

Use case 1: In a perfect world (Success):

1. All entries are successfully posted into the ERP GL.

2. The Integration officer runs a program to extract the “acknowledgement file” from the ERP GL that includes LeaseAccelerator PostingId and the document ID from the ERP.

3. The Integration officer calls LeaseAccelerator API or places the acknowledgement file in the FTP folder.

4. LeaseAccelerator consumes the acknowledgment file and marks the entries in its database as posted.

Use case 2: Error in posting to ERP GL -Full Batch Rejected (Best Practice):

1. Upon posting ledger entries, some ledger entries were post successfully and some fail.

2. The integration officer rollbacks ALL the posted entries, rejects the whole batch.

3. The reason for failure to be identified.

4. LeaseAccelerator period is re-opened.

5. Corrections made in LeaseAccelerator.

6. LeaseAccelerator period closed again.

7. Another batch of all the entries are re-generated and sent to the ERP GL.

Use case 3: Error in posting to ERP GL -Partial Posting:

1. Upon posting ledger entries, some ledger entries were posted successfully and some failed.

2. The integration officer runs a program to extract the “acknowledgement file” from the ERP GL that includes LeaseAccelerator PostingId and the document ID form the ERP for the posted entries only.

3. The integration officer calls LeaseAccelerator API or places the acknowledgement file in the FTP folder.

4. LeaseAccelerator consumes the acknowledgment file and marks the entries in its database as posted. (The entries that failed in posting will not be included)

5. The reason(s) for posting failure for the failed entries are investigated and identified.

6. LeaseAccelerator period is re-opened.

7. Corrections are made in LeaseAccelerator.

8. LeaseAccelerator period is closed again.

9. User generates ledger entries export again. LeaseAccelerator will exclude all entries marked as posted and will generate a complementary batch that only include the entries not marked as posted.

10. The new batch is posted to the ERP GL.

11. A new acknowledgment file is generated and sent back to LeaseAccelerator.

Note: LeaseAccelerator period was not re-opened until the posting acknowledgment round trip was completed.

Exporting ledger entries without closing the period:

Caution: The following case can cause risk of discrepancy between ERP GL and LeaseAccelerator ledger entries:

The risk occurs in any of the following cases:

1. Ledger entries (batch #1) are exported and sent to the ERP GL while LeaseAccelerator period is OPEN.

2. A user applies changes into LeaseAccelerator that affects accounting information. (Since none of the entries are marked as posted, LeaseAccelerator remove some entries and add new entries to reflect the changes).

3. Meanwhile; batch#1 entries are successfully (or even partially) posted to ERP GL.

4. The integration officer generates a posting acknowledgment file and tries to send it back to LeaseAccelerator.

Now, the following problems occurred:

1. When LeaseAccelerator tries to apply the posting acknowledgment file, it will generate errors as some of the entries posted in the ERP were deleted from LeaseAccelerator.

2. Batch #1 already fully or partially posted into the ERP GL includes wrong entries.

3. The new ledger entries export file from LeaseAccelerator cannot be posted into the ERP GL, otherwise will duplicate some entries.

4. Account balances in LeaseAccelerator and ERP GL are not properly synchronized.

To recover from this situation:

1. All batch entries posted into the ERP GL must be reversed.

2. The LeaseAccelerator support team must be called in to remove all entries for this period.

3. All ledger entries for this period in LeaseAccelerator must be regenerated.

As general rules:

• Close the LeaseAccelerator period before generating Ledger entries.

• Do not re-open the LeaseAccelerator period until the posting acknowledgment round trip is complete OR the ledger entries are totally rejected (nothing was posted to ERP GL).

Additional use cases

Which way to go?

LeaseAccelerator generates a set of ledger entries that should be extracted and posted to your ERP General Ledger on a monthly basis (as per the fiscal period in your ERP).

Think of LeaseAccelerator as a subledger to your lease portfolio, and just like any subledger, the fiscal period for the subledger must be closed first then the entries are extracted and posted into the ERP General ledger before the ERP GL – end of fiscal period - closing process.

The sequence should be:

• Users enter all portfolio and lease assets events while the fiscal period in LeaseAccelerator is open.

• Close the fiscal period in LeaseAccelerator to prevent any further entries / changes.

• Export ledger entries through any of LeaseAccelerator’s integration methods.

• Handle the exported entries in the ERP middleware; LeaseAccelerator will export ledger entries in one file. This file can be large and include 10s of thousands of lines. So, depending on the limitations of the ERP or the company policy, clients may need to split the file into many smaller files.

• Post the files into the ERP General Ledger.

• Send the posting acknowledgment file(s) to LeaseAccelerator so that the posted entries in your ERP can be marked as “Posted” in LeaseAccelerator. This flag will prevent LeaseAccelerator from changing or deleting these records.

• Once the acknowledgment roundtrip is completed, then users – if they need – can re- open the period to make necessary changes to the lease portfolio.

• The changes may force LeaseAccelerator accounting engine to generate different entries, but since the original entries are marked as “Posted,” LeaseAccelerator will generate incremental, additional, or corrective entries with the “delta” with status “New”.

• Users must then re-close the period

• The client integration team should now extract the non-posted entries only, so the extracted file will only include the new entries.

• Once extracted through API or FTP, the status in LeaseAccelerator will change to “Transferred.”

• The new entries should be posted to the ERP GL

• The posting acknowledgment roundtrip is repeated for these new entries.

Now let us assume your portfolio includes 1000 deals (lease contracts or schedules) and each deal has 50 assets. This portfolio generates ledger entries with 100,000 lines (debits and credits). So that when the period is closed, and the entries are extracted, the integration team will have a file of 100,000 records.

Question 1

Do you need to post the entries to multiple ERP instances?

For example, a client may have two or more ERPs - say SAP, Oracle and JDE at the same time - or may have a ledger (set of books) in LeaseAccelerator abiding to 842 standards while another ledger for European operations abiding to IFRS16.

Answer a): Yes

In the solution design you should determine how to extract the ledger entries for each instance. Maybe through having a separate ledger for each corresponding instance, or maybe having one ledger (set of books) in LeaseAccelerator while using parameters to extract the required ledger entries for each instance (such as country code, company code, business unit, any of the segments, etc.).

For file-based integration, you will need to schedule a ledger export for each instance (using the parameters in the UI) and for APIs you will need to call the APIs, once for each instance, and specify the correct request parameters to receive the correct payload.

Answer b): No

Then you would extract all ledger entries in one file. For file-based, you will schedule LeaseAccelerator to generate and export the file once and for the API method you will need to call the API once as well.

So now you have one file extracted per instance on your side.

Question 2

For each instance, will you need to split the file into smaller files (batches – or Journal vouchers)?

Answer a): No

Then you will have one Journal voucher posted in the ERP General Ledger with 100,000 debit and credit lines. If – for any reason – one line fails to post correctly, the posting process will fail, and the full batch will be rejected from the ERP.

In such case, you don’t need to do the posting acknowledgment roundtrip as nothing was posted in the GL and you only need to:

• Analyze the reason for failure

• Agree on the solution

• Re-open the period in LeaseAccelerator

• Apply corrections

• Close the period

• Regenerate the ledger export

• Try again to post

• Once the posting is successful, complete the posting acknowledgment roundtrip and you should see all entries in LeaseAccelerator as Posted. (If you choose to display non-posted entries, the report will be empty).

Answer b): Yes

Then you will split the files into smaller files (Journal vouchers) and you can use the key identifier PostingId (LXnnnnn) to divide the file into smaller and balanced entries. Since PostingId groups the entries for a single deal, then – as per the example above – you will end up with 1,000 smaller files (batches). 

Now the integration officers will start posting these batches into the ERP GL, one by one.

Question 2-b-1:

If any of these JVs fail to post into the ERP, will you cancel the whole posting process and roll back the previously posted JVs? (all or nothing)? Or you will allow partial posting?

As per the example above, assume one of the 1,000 Journal vouchers was addressing a retired / invalid Cost Center so the ERP rejected the Journal voucher. Will you post the 999 accepted JVs or will you reject all JVs and roll back the preceding JVs which were correctly posted in your ERP GL?

Answer 2-b-1-a) Yes, reject all the JVs and roll back the preceding ones – nothing is posted.

In such case, you don’t need to do the posting acknowledgment roundtrip as nothing was posted in the GL and you only need to:

• Analyze the reason for failure

• Agree on the solution

• Re-open the period in LeaseAccelerator

• Apply corrections

• Close the period

• Regenerate the ledger export

• Re-split the files into balanced JVs

• Try again to post

• Once the posting is successful, complete the posting acknowledgment roundtrip for all the posted JVs and you should see all entries in LeaseAccelerator marked as Posted. (If you choose to display non-posted entries, the report will be empty).

Answer 2-b-1-b) No, we will allow partial posting

Back to the example, assume 10 JVs were rejected (failed to post in the ERP GL), and you have 980 JVs successfully posted.

In this case, you should keep the period CLOSED in LeaseAccelerator until the posting acknowledgment roundtrip is completed. Until now, LeaseAccelerator assumes that the ledger entries are not posted in the ERP since the roundtrip is not completed yet.

The users need to:

• Complete the posting acknowledgment round trip for the 980 JVs successfully posted.

• Make sure they were marked as posted in LeaseAccelerator by generating the ledger export report and EXCLUDING posted entries. The report should only include the 20 unposted JVs. (Their status should be = “Transferred”). In the same report, if the user selected to display the “Posted” entries, it should only display the 980 JVs.

• Analyze the reason(s) for failure

• Agree on the solution

• Re-open the period in LeaseAccelerator

• Apply corrections

• Close the period

• Regenerate the ledger export with parameter “Exclude Posted Entries.”

• The resulting ledger export shall only include the JVs for the unposted entries.

• Re-split the files into balanced JVs (if you need to)

• Try again to post

• Once the posting is successful, complete the posting acknowledgment roundtrip for all the posted JVs and now you should see all entries in LeaseAccelerator marked as Posted. (If you choose to display non-posted entries, the report will be empty).

Question 3:

If – after the period is closed in LeaseAccelerator – we need to re-open and do corrections in LeaseAccelerator?

Answer: As long as the roundtrip is completed and all ledger entries in LeaseAccelerator are marked “Posted” as per the corresponding posted entries in your ERP GL, then you can re-open the period and do any corrections. LeaseAccelerator will generate incremental entries but will not touch the posted entries.

Then you should:

• Re-close the period

• Extract the incremental entries only (by choosing to Exclude Posted Entries)

• Post the incremental entries to your ERP GL

• Compete the posting acknowledgment roundtrip to mark the new entries as posted and keep LeaseAccelerator synchronized with your ERP

Parameters for Generating Ledger Entries

Regardless of the integration method selected (RESTful APIs or file-based FTP), or as a scheduled report, LeaseAccelerator allows users to specify several parameters to generate ledger entries:

General ledger data mapping

As part of the general ledger integration, LeaseAccelerator both sends data to the general ledger and receives data from the general ledger.

Entries from LeaseAccelerator to general ledger

The ledger export file that LeaseAccelerator sends to the general ledger during the GL-C1 connection in the integration process includes the following fields:

Supported formats for file-based exports are: XLSX, XML, TSV, Pipe delimited and CSV.

Light-touch customizations:

LeaseAccelerator’s technical integration team offers clients a variety of modifications to the layout above to suit their specific needs.

For example, clients may request:

• Removing columns or changing the format of data.

• Adding columns with hard-coded content.

• Changing column headers.

• Removing column headers.

Additionally, for the ledger entry credit and debit amounts, light touches allow our clients to have them as any of the following forms:

• Debit amount and Credit amount in two separate columns.

• One column indicating “DR or CR” and another column for the amount.

• One Column indication “40” for Debit and “50” for Credit and another column with the amount.

• One column for the amount defaulting +ve value for Debit and -ve value for Credit (and vice versa).

Posting acknowledgement to LeaseAccelerator

When the ERP receives the entries from LeaseAccelerator for the general ledger, the ERP returns an acknowledgment to LeaseAccelerator as part of the GL-C2 connection in the integration process. The acknowledgment contains the following fields:

In addition to API and SFTP, the acknowledgment file can be also uploaded through the Bulk Import feature in the user interface.

Splitting ledger entries export file:

Different ERP systems set specifications for ledger entries so that they can be ingested into its General Ledger system. Specifications probably would require some post processing to the exported ledger entries export. Ledger entries export generates one file at a time which is balanced (total debits = total credits).

Regardless of the processing and the criteria to split the file (by date, by currency, by a specific segment, etc.), each resultant group of entries must constitute balanced entry otherwise the ERP will reject it.

After splitting the Ledger Export file, integration officers may choose (or to comply with ERP specifications) to have a maximum number of lines per entry.

There are several techniques to split Ledger Entries export file into multiple files while maintaining a balanced entry. For example:

1. Use LeaseAccelerator balanced entries (PostingID):

Every entry in the Ledger Export file (line) will have a unique LedgerEntryLineID while a number of entries will have the same PostingID and PostingEntryID. Entries sharing the same PostingID or PostingEntryID constitute a balanced entry (Journal voucher) for one schedule.

Accordingly, upon splitting Ledger Entries file, if you maintain all the lines sharing the same PostingID or PostingEntryID together, then the resultant file will constitute a balanced entry.

This way, the Ledger export file will be split into several Journal vouchers equal to the number of deals (schedules) in LeaseAccelerator.

2. Split balanced entries based on record count and PostingId

After importing the Ledger Export file, integration officers may choose (or to comply with ERP specifications) to have a maximum number of lines per journal entry posted into their ERP.

For example, if the max number of lines per the new file should be 999, then integration officers can build programs to:

• Sort ledger entries by Ledger Date, Currency and PostingId or PostingEntryId (to have all entries with the same date and currency in sequence) to make sure that all entries constituting a balanced entry are grouped together.

• Count the number of entries that can be posted in one journal entry allowing a “safety” tolerance. (In the case of a max of 999 entries, the counter should import 800 lines only).

• Check the PostingId or PostingEntryId for the last imported line.

• Check the PostingId or PostingEntryId for the following line (that is not imported).

• If they are the same, then you are splitting a balanced entry by importing some lines and leaving others. Meaning the ERP would reject the Journal entry as it will not be balanced. In such case, the program should import the following lines until the PostingId or PostingEntryId changes.

• This method ensures that when the program splits the ledger entries, the imported chunks will always be balanced.

In this case, the posting acknowledgment should use the PostingId(s) or PostingEntryId(s).

3. Split balanced entries based on record count and LedgerEntryLineId

After importing the Ledger Export file, integration officers may choose (or to comply with ERP specifications) to have a maximum number of lines per journal entry posted into their ERP.

For example, if the max number of lines per the new file should be 999, and the integration officer decides to have 500 lines per Journal voucher only, then integration officers can build programs to:

• Sort ledger entries by Ledger Date, Currency (to have all entries with the same date and currency in sequence).

• Import 499 lines from the LeaseAccelerator- generated ledger export file (as long as the date and currency do not change).

• Add the Debit and the Credit then add line 500 as a balancing entry addressing a suspense/ settlement account in the ERP GL.

• Repeat the same process until all ledger export entries are consumed.

• Post the resulting files and the balancing entries will eventually net to zero.