Migrate from MaxCredible to Twenty CRM

MaxCredible Debtors are the primary entity, holding contact details, credit risk scores, payment behavior history, and segment assignments. We map Debtors flagged as business entities to Twenty CRM Company; individuals map to Twenty CRM Contact. The debtor identifier (external_id) is preserved as a custom field for audit trail and cross-reference during the warranty period. Segmentation tags from MaxCredible migrate as multi-select picklist values on the Company or Contact.

MaxCredible Invoices are linked to Debtors via foreign relationship and include amount, due date, status, and aging bucket. We map them to Twenty CRM Opportunity if the invoice represents a sales deal in progress, or to a custom Invoice object if the customer requires receivables tracking. The MaxCredible invoice status (open, overdue, paid, disputed) maps to a custom Opportunity stage or Invoice status field. The debtor reference becomes a Company or Contact lookup in Twenty.

Credit notes issued against invoices adjust the net receivable balance. We map them to a Twenty CRM custom object with a lookup to the parent Invoice (or Opportunity), the adjustment amount, reason code, and effective date. The net receivable balance is recalculated in Twenty post-migration to reflect all credit note offsets against open invoices.

MaxCredible Reminders are time-based tasks triggered by invoice aging rules. We map them to Twenty CRM Task records with the debtor as the related Company or Contact, the invoice as a related custom object or Opportunity, and the due date and priority preserved. The workflow logic driving the reminder trigger is documented but not migrated as automation; the customer's admin rebuilds the aging-based task rules in Twenty's task settings.

The receivables ledger aggregates all open items per debtor. We extract the ledger as a structured dataset keyed by debtor_id and invoice_id, and reconstruct it in Twenty CRM as either a custom Receivables Ledger object or a report view using Twenty's native charting. Some aggregation fields may require post-migration calculation if the destination schema uses standard opportunity amounts.

MaxCredible tracks outbound communications across email, SMS, and WhatsApp, each with channel-specific metadata. We normalize email logs to Twenty CRM Email (linked to the Company or Contact), SMS logs to Task with a custom channel field set to SMS, and WhatsApp logs to Note with the thread context preserved as body text. The original channel-specific carrier metadata (present on SMS) is stored in custom fields on the Task record. We flag any communications requiring rich thread-context preservation during scoping.

MaxCredible's brand voice settings are stored as platform configuration with no structured export mechanism. We extract the template body copy, variable placeholders, and channel assignments as a written document delivered to the customer's marketing or operations team. The customer manually rebuilds these in Twenty CRM's Email Template editor. We do not migrate the tone-of-voice rules as code because they cannot be extracted in a machine-readable format from MaxCredible.

MaxCredible's AI-driven credit risk score is a computed snapshot per debtor. We migrate the current score value and the effective date into a custom number field on the Company record in Twenty CRM. The underlying behavioral data (payment timing history, dispute frequency) is not separately exposed for export by MaxCredible, so the destination cannot reproduce the identical AI-generated score without access to the raw behavioral dataset. We document this limitation and recommend recalibrating credit risk models in Twenty post-migration.

MaxCredible user accounts define access and role assignments. We export user records including name, email, and role. In Twenty CRM these map directly to User records. Any user without a matching email in the destination requires admin provisioning before migration. The MaxCredible role assignments are documented for the admin to map to Twenty CRM workspace roles post-migration.

MaxCredible supports user-defined fields on debtor, invoice, credit note, and reminder objects. We extract the full field schema during scoping and deliver it as a configuration checklist for recreation in Twenty CRM's workspace settings. Custom field values migrate as data after the schema is deployed. Field types are mapped to their nearest Twenty CRM equivalents (text to text, number to number, date to date, picklist to select).

Documents linked to debtors or invoices (contracts, proof of delivery, correspondence PDFs) are extracted as binary files and stored alongside the migrated records in Twenty CRM. File format compatibility (PDF, DOCX, XLSX, images) is preserved. We store the original MaxCredible file URL or reference in a custom field on the attachment record for audit trail during the post-migration warranty period.

MaxCredible connects to ERP systems via XML file uploads over SSL with a proprietary schema for Oracle and SAP. The integration mapping rules, sync frequency, and data transformation logic are MaxCredible-specific and cannot be migrated directly to Twenty CRM's REST API architecture. We document the current integration endpoints, XML schema patterns (validated from sample files during discovery), and the data flow direction so the customer's IT team or an implementation partner can rebuild the integration against Twenty's API.