Sprout Conversion Process

Sprout has a detailed process for converting an existing system (often referred to as a donor system) to Sprout during the go live.  This is a GUI driven process within Sprout that is only accessible durng the intial install with a clean system.  It is not accessible by users, these tasks are performed in conjunction with Anovys support staff.

This section describes that process.

1. Executive Overview

Sprout conversion is performed in two controlled phases:

1. Import a balanced trial balance (GL only)
2. Rebuild subledgers (AR, AP, Inventory) using conversion transactions

To ensure accuracy and auditability:

• AR, AP, and Inventory are NOT imported via the trial balance
• These balances are recreated from detailed records

Because these accounts are excluded:

The trial balance must be rebalanced prior to import using conversion accounts.  Conversion accounts are temporary and net to zero once all subledger detail is recreated.

2. Trial Balance Import

2.1 Source Trial Balance

• Exported directly from the legacy system
• No filtering or edits
• Must be fully balanced

This remains the source of truth

2.2 Accounts Excluded from Import

The following are removed from the import file:

• Accounts Receivable (AR) Accounts
• Accounts Payable (AP) Accounts
• Inventory Accounts - including specific/override inventory accounts

2.3 Why These Are Excluded

To prevent:

• Double counting (GL + subledger)
• Loss of document-level detail
• Broken application of payments and inventory movements

When the subledgers are recreated with open AR, open AP and inventory Sprout will create the correct entries, rebuilding the native GL account.  The offsetting account in that transaction is the conversion clearing account which results in net zero.

3. REQUIRED STEP — Rebalancing the Trial Balance

3.1 What Happens

Removing AR/AP/Inventory causes the trial balance to go out of balance.

This is expected.

3.2 Required Action

You must add conversion balancing lines.

3.3 Rule

For each excluded category:

3.4 Example

If removed:

• AR = 81,830.40
• Inventory = 701,057.34
• AP = (109,374.33)

Add:

Dr AR Conversion           81,830.40

Dr Inventory Conversion    701,057.34

Cr AP Conversion          109,374.33

3.5 Result

After this step:

• Trial balance is balanced 
• AR/AP/Inventory = 0 
• Conversion accounts hold removed values 

4. Conversion Account Design

4.1 Required Accounts

• AR Conversion
• AP Conversion
• Inventory Conversion

These accounts should be numbered immediately after their respective default accounts.

4.2 Design Principle

Each conversion account is used for BOTH:

• Trial balance balancing (offset)
• Subledger reconstruction (clearing)

4.3 Expected Final State

After full conversion:

All Conversion Accounts = 0

5. CRITICAL VALIDATION CHECKPOINT 

5.1 After TB Import — Before Subledger Rebuild

At this point:

• Trial balance has been imported
• AR, AP, and Inventory are zero
• Conversion accounts hold their values
• Subledgers have NOT yet been rebuilt

5.2 What You Should Expect

Balance Sheet

• Will match the legacy system exactly
• However:
• AR is replaced by AR Conversion
• Inventory is replaced by Inventory Conversion
• AP is replaced by AP Conversion

Income Statement

• Will match the legacy system exactly

Because:

• No revenue or expense activity has been created
• Only balance sheet reclassification has occurred

5.3 Key Principle

No financial values have changed — only the accounts holding them.

5.4 How to Reconcile

To compare systems:

Old AR        = New AR + AR Conversion 

Old Inventory = New Inventory + Inventory Conversion 

Old AP        = New AP + AP Conversion 

5.5 Expected State Checklist

• Trial Balance balances
• Balance Sheet matches legacy system
• Income Statement matches legacy system
• AR/AP/Inventory = 0
• Conversion accounts populated

6. AR Conversion (Customers)

6.1 Behavior

Create Conversion Invoices:

• No inventory
• No revenue
• No shipment logic

6.2 GL Entry

Dr Accounts Receivable 

Cr AR Conversion 

6.3 Result

• Customer balances correct
• Aging accurate
• Payments can be applied

7. AP Conversion

7.1 Behavior

Create Conversion Bills:

• No PO
• No receiving
• No expense creation

7.2 GL Entry

Dr AP Conversion 

Cr Accounts Payable 

7.3 Result

• Vendor balances correct
• Payables aging accurate

8. Inventory Conversion

8.1 Behavior

Create Inventory Conversion Entries:

• Creates lots
• Sets quantity and cost
• No PO or vendor required

8.2 GL Entry

Dr Inventory 

Cr Inventory Conversion 

8.3 Result

• Inventory value correct
• Traceability established

9. Full Conversion Flow

1. Export Trial Balance
2. Remove AR/AP/Inventory
3. Add conversion balancing lines
4. Import Trial Balance
5. Load AR/AP/Inventory
6. Validate

10. Final State After Conversion

11. What NOT To Do

• Do NOT import AR/AP/Inventory in TB
• Do NOT create fake POs
• Do NOT generate fake revenue or expenses
• Do NOT adjust retained earnings manually

12. Audit & Traceability

All conversion transactions must:

• Be tagged as Conversion
• Be clearly identifiable as Opening Balances
• Be traceable back to source data

13. Conversion Sign-Off Checklist

Setup

• AR Conversion Account
• AP Conversion Account
• Inventory Conversion Account

Validation

• Source TB balances
• Source income statement and balance sheet saved with the go live certification
• AR/AP/Inventory removed
• Conversion lines added
• Import TB balances
• Sprout Balance Sheet matches legacy system
• Sprout Income Statement matches legacy system
• Subledgers loaded
• Conversion accounts = zero

14. Final Summary

This process ensures:

• Clean financial starting point
• Full subledger detail
• No double counting
• Complete audit trail