Migrate from SoftLedger to Microsoft Dynamics 365 Business Central

SoftLedger Locations are the top-level entity container carrying their own currency, address, COA, and operational settings. We split each Location into a D365 Company (legal entity) if the customer requires separate legal-entity reporting, or into a Department tagged with financial dimensions if a single D365 company can absorb the entity. The split decision is made during scoping based on the customer's consolidation requirements, legal entity count, and tax reporting needs. Parent-child Location hierarchy maps to D365 dimensions or separate company hierarchies.

The COA defined per SoftLedger Location maps to D365's Chart of Accounts. In D365 Business Central, we create the COA at the company level with account numbers, names, types (posting, heading, total), and tax posting setup. Account categories map to D365's account category grouping. In D365 Finance and Operations, the COA can be shared across legal entities or isolated per entity. We flag any Location-specific COA customizations (custom account types, extended text) for manual extension in D365.

SoftLedger Customer records map directly to D365 Customer with name, address, payment terms, currency, and invoice and delivery addresses. D365 splits Customer into CustTable with address and contact subtables, which we map field-by-field. Any SoftLedger custom fields on Customer are pre-created as D365 extension fields before migration. Payment terms map to D365 PaymentTermId; customer currency maps to CurrencyCode.

SoftLedger Vendor records map to D365 Vendor (VendTable) with equivalent fields: name, address, payment terms, currency, 1099 eligibility, and W-9 status for US vendors. AP-specific SoftLedger fields map to D365 Vendor posting profiles and invoice co-related settings. Outstanding AP balances are migrated as open vendor ledger entries in D365's AP module.

SoftLedger Journal Entries with Lines map to D365 General Journal Lines. Each line carries Account (G/L Account number), Debit, Credit, Currency, and Description. For multi-currency entries, we extract the effective exchange rate and any SoftLedger-specific override rate explicitly and apply it to the D365 journal line. Dimensional tags from SoftLedger Dimensions map to D365 financial dimension values that we create and validate before migration. Source references (invoice ID, vendor ID) migrate as journaling text or reference fields.

SoftLedger AR Invoices map to D365 Sales Invoice records. The SoftLedger invoice number becomes the External Document No. on the D365 invoice; the invoice date becomes the Invoice Date; amounts map to Amount and TaxAmount. Open AR invoices are migrated with status Open so that the D365 accounts receivable module picks up the outstanding balance. Closed invoices migrate as posted invoices for historical record. Customer lookup resolves via email or account name match.

SoftLedger AP Invoices map to D365 Purchase Invoice records. The vendor invoice number becomes the Invoice Account and External Document No. on the D365 vendor invoice; invoice date and amount map directly. Open AP invoices migrate with status Open so that D365's AP module reflects the outstanding vendor payable. Vendor lookup resolves via vendor name or vendor ID mapping created during the vendor migration phase.

SoftLedger Bank Transactions map to D365 Bank Account Transactions linked to the corresponding BankAccountTable. We preserve the reconciliation status from SoftLedger: unreconciled items land in D365 as open (reconciliation flag not set) so that the finance team completes bank reconciliation in the new system. Reconciled items migrate as cleared. Bank statement import format (CAMT, MT940, or generic) is documented for the customer's bank reconciliation setup in D365.

SoftLedger beginning balances use a dedicated upload mechanism rather than standard journal entry posting. We structure the D365 opening balance upload as a General Journal with Opening Transaction = Yes, using D365's Opening Balance Journal template or the Configuration Package for trial balance seeding. The upload is sequenced after all G/L account definitions are confirmed and before any historical transaction migration begins, so that the trial balance is seeded correctly. We validate that total debits equal total credits per entity before committing.

SoftLedger Dimensions (e.g., department, cost center, project) tag journal lines with organizational attributes. We discover the full dimension schema during scoping, create corresponding Financial Dimensions in D365 (Dimensions > Financial Dimensions > Financial dimension values for each), and map every dimensional tag assignment to the D365 DefaultDimension and DimensionValue references on journal lines. In D365 Finance, we also configure the dimension framework at the main account level for default financial dimension inheritance.

SoftLedger custom fields on any standard object (Customer, Vendor, Journal Entry, etc.) are discovered during scoping, their data types are mapped to D365-compatible types, and the destination fields are created before migration data is loaded. In Business Central, we use AL extensions or the table extension designer; in Finance and Operations, we use Power Apps portal metadata or the extension framework. Any custom fields that cannot be mapped directly (e.g., SoftLedger-specific picklist values with no D365 equivalent) are flagged for customer decision during scoping.

SoftLedger stores custom financial report definitions as JSON configurations referencing account IDs and dimension tags. These do not migrate as executable reports because D365's report designer (Report Designer, Power BI, or Financial Reporter) uses a different schema. We extract the report JSON, identify the referenced account IDs, and produce a written document mapping those IDs to D365 account numbers with a description of the report layout for the customer's financial analyst or D365 partner to rebuild in the destination report designer.

SoftLedger user accounts and role-based permissions are tied to the organization's SSO and identity provider configuration and do not have a direct D365 equivalent that can be migrated as data. We extract the list of SoftLedger users and their access scope (which Locations they can see, which modules they can access) and produce a written permission matrix. The customer's D365 administrator maps this to D365 Security Roles, duty privileges, and field-level security in the destination system using Azure Active Directory for identity.