Migrate from metasfresh to Acumatica

Branch and Sub-account dimensional accounting has no metasfresh equivalent

Acumatica's Financial Management module requires every transaction to carry a BranchID and sub-account (SegmentValue) combination — this is how Acumatica produces dimensional P&L and balance sheet reports across legal entities or cost centers. metasfresh stores GL postings without a branch dimension; the C_AcctSchema defines posting combinations but no branch context. When migrating invoices and payments, every record requires a BranchID assignment. If metasfresh has a single-company setup, we assign a default branch from the Acumatica configuration. If the metasfresh deployment uses multiple org units (AD_Org records), we map each org to a separate Acumatica Branch and validate that all GL accounts have sub-account combinations active in each branch. Without this mapping, Acumatica rejects the documents at posting time with an 'Account Sub combination not found' error. The sub-account chart of accounts must be designed in Acumatica before data migration begins, and the metasfresh account structure must be audited to identify which accounts map to which sub-segments.

TaxZone configuration does not carry over — tax amounts must be recalculated

metasfresh calculates tax on invoices using C_Tax and C_TaxCategory definitions embedded in the product and partner records. The tax jurisdiction mapping (which tax applies to which state or country) is stored in metasfresh as part of the tax configuration. Acumatica calculates tax using TaxZone and TaxID combinations tied to the customer address and the tax category of the line item. The tax amounts from metasfresh cannot be directly transferred as line-level amounts in Acumatica because Acumatica will recalculate them during document release. Instead, we preserve the metasfresh tax amounts in custom fields on the invoice lines and advise the Acumatica administrator to configure TaxZone rules that produce equivalent tax amounts before the document is released. If exact tax amount preservation is a regulatory requirement (for example, for VAT audit trails), the invoice lines can be entered with Tax Included pricing and the original tax amount held as a reference note — but this requires explicit sign-off from the finance team and may not be compatible with standard Acumatica tax reporting.

DATEV-specific accounting data requires German localization reconfiguration

metasfresh includes a DATEV export interface for posting records and master data to German tax advisors in the DATEV format (exported via the DATEV accounting interface). This export captures account numbers, posting dates, and amounts in the specific DATEV CSV/ASCII format. Acumatica does not include a native DATEV export module — German localization is handled through Acumatica's localization framework or third-party add-ons. The metasfresh DATEV postings represent the accounting output of the ERP, not the source documents themselves. When migrating, we bring the source documents (invoices, payments, bank statements) into Acumatica. After migration, the Acumatica finance team must configure the German localization (Chart of Accounts mapping to DATEV account numbers, tax jurisdiction settings, and posting rules) to reproduce DATEV-compatible output. We export the metasfresh DATEV postings as a reference file that the tax advisor or Acumatica partner can use to validate the new system's accounting output.

metasfresh custom extension tables need manual schema mapping

metasfresh is built on an open-source Java/PostgreSQL stack that allows developers to add custom columns directly to standard tables (AD_Column + AD_Table configuration) or create entirely new tables via the metasfresh metadata framework. These custom fields and tables are often used by DACH-region clients to handle industry-specific data (lot tracking for food/beverage, catch weight for fresh produce, multilingual product descriptions). Acumatica handles custom fields through its Customization Project editor (Customization > Customization Projects) and extension tables via the Acumatica Framework. There is no automated translation between metasfresh custom column definitions and Acumatica custom fields. We inventory all metasfresh custom columns during the discovery phase and produce a mapping plan that identifies which custom fields map to standard Acumatica fields, which require Acumatica custom fields (created by an Acumatica developer), and which metasfresh custom fields have no equivalent in Acumatica (flagged for manual data re-entry or custom development). This phase is scoped separately because it may require Acumatica developer involvement.

Inventory valuation methods differ — Average Cost vs. Standard Cost mapping

metasfresh supports multiple inventory valuation methods per product (Average Cost, Standard Cost, LIFO, FIFO) configured through the costing method field on the product. Acumatica's inventory valuation uses the Valuation Method field on the InventoryItem screen (IN.202000) with options including Average, Standard, and FIFO. The challenge is that metasfresh may store per-warehouse costing configurations that Acumatica consolidates at the item class or site level. If the metasfresh setup uses different costing methods per warehouse for the same product, Acumatica cannot replicate this split — the item will use a single valuation method at the company or item-class level. We inventory the costing method assignments in metasfresh before migration and surface any conflicts where one product has multiple costing methods. The resolution requires the finance team to decide on a primary costing method for Acumatica, with the alternative method's cost data preserved as a custom reference field.