Migrate from Aqilla to Dolibarr ERP

Aqilla's hierarchical account structure with analysis codes maps to Dolibarr's accounting module. We flatten the hierarchical account codes into Dolibarr's flat account plan and create custom fields on third-party records to carry the original Aqilla analysis code values. Where Aqilla uses multiple analysis dimensions per transaction, we map the primary analysis code to a dedicated custom field and flag secondary codes in a notes field for manual assignment.

Aqilla customers map directly to Dolibarr third parties with the Type set to Customer. Contact details, currency settings, credit limits, and tax registration migrate to the corresponding Dolibarr third-party fields. Open AR items (unpaid sales invoices) migrate as invoice records linked to the third party. In Dolibarr, customers and suppliers share the same third-party table; we set the Type on each record based on Aqilla's customer or vendor classification.

Aqilla vendors map to Dolibarr third parties with Type set to Supplier. Multi-currency settings and payment terms migrate to Dolibarr's supplier fields. Purchase invoices and credit notes carry over as Dolibarr supplier invoice records with line-item detail preserved.

Aqilla's container/subordinate invoice structure (header with subordinate line rows) maps to Dolibarr's supplier invoice header. We extract the header-level fields (invoice number, date, supplier reference, due date, currency) and create Dolibarr supplier invoice records. The subordinate lines insert as Dolibarr invoice line rows at import time.

Aqilla invoice lines with quantity, unit price, tax code, and analysis codes migrate to Dolibarr supplier invoice lines. We map the Aqilla tax code to the corresponding Dolibarr VAT rate. Analysis codes on each line are stored as custom fields on the line record or flagged in a migration notes column for the customer's admin to assign to the correct Dolibarr expense account.

Aqilla order-to-cash invoices with header, line items, tax breakdown, and payment terms map to Dolibarr customer invoices. We preserve the invoice status (Draft, Validated, Paid) and carry forward any payment terms and credit note relationships. Invoice PDFs are extracted from Aqilla's document store and re-associated to the corresponding Dolibarr invoice record by reference number.

Aqilla journal entries (header with debit and credit lines) map to Dolibarr accounting entries. We preserve the effective date, journal reference, and line amounts. Open or unposted journals require a period-status checkpoint before cutover — if a journal posts to a period locked in Aqilla but not yet locked in Dolibarr, balances will disagree. Inter-company journals are decomposed into individual entity postings with elimination entries constructed in a separate step.

Aqilla fixed asset records (acquisition date, cost, depreciation method, book values) map to Dolibarr's Assets module if enabled. Depreciation schedules migrate as numeric values; the actual depreciation calculation logic is Aqilla-native and cannot transfer. We flag mid-period acquisitions for period-adjustment review post-load.

Aqilla inventory items with stock valuation, costing method, and on-hand quantities map to Dolibarr Product records. Current stock positions migrate as Dolibarr stock warehouse entries. Open purchase orders and sales commitments require additional mapping to Dolibarr's order management module. The inventory costing method is stored as a custom field because Dolibarr's standard costing differs from Aqilla's implementation.

Aqilla bank accounts with imported transactions and reconciliation positions map to Dolibarr bank accounts. Reconciled items carry their reconciliation flag; unreconciled items land as open bank statement lines for re-reconciliation in Dolibarr. We flag unmatched items in a reconciliation exceptions report for the customer's finance team to review post-migration.

Aqilla's multi-entity mode enforces inter-company journals that cross-reference two or more entities. Dolibarr has no native multi-company module, so we decompose each inter-company journal into individual entity postings and construct elimination entries as separate journal lines. We build an entity mapping table from Aqilla and create corresponding Dolibarr third-party records for each entity, with elimination entries posted to a dedicated inter-company elimination account.

Aqilla tax codes tied to Making Tax Digital submission capability map to Dolibarr VAT rate configurations. MTD active obligations should be confirmed with HMRC before migration. Dolibarr does not have native MTD filing; we recommend a third-party MTD module or external submission process and flag this as an admin rebuild item. Submission history migrates as a document attachment.

Aqilla user seats (Core, Business, Pro, Enterprise) with tier-gated feature access map to Dolibarr users. We capture the full user-role inventory, map each user to a corresponding Dolibarr user account, and produce a role-mapping matrix for the customer's admin to assign Dolibarr permissions by module access. Aqilla's permission-by-area model differs from Dolibarr's per-module activation approach; we document the mapping during discovery.

Aqilla's document storage linked to transactions migrates by extracting documents from the source and re-associating them with the corresponding Dolibarr record by reference number. Dolibarr stores documents in the /documents/ directory per object. We map the Aqilla document path structure to Dolibarr's document storage convention and verify that Dolibarr's file size limits and allowed extensions accommodate the migrated file set.

Aqilla budget versions with period granularity and account association migrate as numeric budget values. The calculation formula logic that underpins Aqilla's forecast engine does not transfer because Dolibarr uses a different reporting engine with distinct formula syntax. We extract the latest approved budget version as raw numeric rows and flag any models that cannot be fully reconstructed from the data alone.