Migrate from MaxCredible to Salesforce Sales Cloud

MaxCredible Debtors map to a Salesforce Account (the company-level record) with a primary Contact record created from the debtor's contact details. If the debtor has multiple contacts (billing, accounts receivable, legal), additional Contact records are created under the same Account. The MaxCredible debtor_id becomes the Account's external ID (maxcredible_debtor_id__c) for lookup resolution during invoice import. Credit risk score migrates as a custom field on Account (maxcredible_risk_score__c) and risk model version migrates as maxcredible_risk_model_version__c. The debtor's payment behavior summary migrates as a long-text area field for admin reference.

MaxCredible Invoices map to Salesforce Opportunity. The Opportunity Name uses the invoice number; Amount maps to Amount; CloseDate maps to CloseDate (set to the invoice due date); StageName is set to 'Closed Won' for paid invoices or 'Invoice Sent' for outstanding invoices based on MaxCredible's payment_status property. Invoice number migrates as a custom field (invoice_number__c); original invoice date as invoice_date__c; outstanding balance as invoice_balance__c. The Opportunity is linked to the Account resolved from the parent Debtor record.

MaxCredible Credit Notes map to a Salesforce custom object (Credit_Note__c) with a lookup to the parent Opportunity (mapped from the MaxCredible Invoice that the Credit Note adjusts). Custom object creation is included in the migration scope for Professional tier and above. Fields include: credit_note_number__c (external ID), original_invoice__c (lookup to Opportunity), credit_amount__c, issue_date__c, and status__c (open/closed). The net receivable balance is recalculated in Salesforce after both records are loaded.

MaxCredible Reminders map to Salesforce Task records. The debtor reference resolves to an Account or Contact lookup; the invoice reference resolves to an Opportunity lookup. Reminder due date maps to ActivityDate; reminder body maps to Subject and Description. Status is set to Not Started for open reminders and Completed for fulfilled ones. Recurring reminder patterns are documented as a series of Tasks rather than migrated as a recurrence rule (Salesforce Tasks do not support native recurrence migration).

The MaxCredible receivables ledger aggregates all open items per debtor. We extract it as a structured dataset and map it to a custom Salesforce object (Receivables_Ledger__c) with fields for total_open_amount__c, oldest_open_item_date__c, days_sales_outstanding__c, and payment_terms__c. Aging buckets (current, 1-30, 31-60, 61-90, 90+) migrate as separate custom fields for dashboard reconstruction. This object is linked to the Account.

MaxCredible email communication logs migrate to Salesforce EmailMessage records (body and headers) linked to a Task record on the activity timeline. The WhoId on the Task points to the Contact or Lead resolved from the debtor; WhatId points to the Account or Opportunity. Email subject maps to Task.Subject; send date maps to ActivityDate. Template references are preserved as a custom field (email_template_ref__c) in the Task record for admin reconstruction.

MaxCredible SMS logs migrate to Salesforce Task records with TaskSubtype = SMS (if Salesforce Messaging is enabled) or a custom task type field. Carrier metadata from MaxCredible is preserved in a custom field (sms_carrier__c). SMS body migrates to Task.Description; send date maps to ActivityDate. Thread context is preserved in a custom field (sms_thread_id__c).

MaxCredible WhatsApp logs migrate to Salesforce Task records. Thread context is preserved in a custom field (whatsapp_thread_id__c). Message body migrates to Task.Description; send date maps to ActivityDate. Note that WhatsApp-specific rich context (read receipts, media attachments) is simplified in the Salesforce Task model; we flag any media attachment URLs and document them for the customer's admin to reconnect in Salesforce's native Messaging or a third-party WhatsApp integration.

MaxCredible AI credit risk scores migrate as snapshot values in custom fields on the Account: maxcredible_risk_score__c (number), maxcredible_risk_effective_date__c (date), and maxcredible_risk_model_version__c (text). The underlying behavioral data (payment timing history, dispute frequency) is not separately exposed in MaxCredible's export, so the destination cannot reproduce the exact same score without access to the raw dataset. We document this limitation and recommend recalibrating credit risk models in Salesforce Data Cloud or a third-party scoring tool post-migration.

MaxCredible tone-of-voice templates are stored as platform configuration rather than structured data. We export the template body copy and variable placeholders as a written inventory document with template name, body, variables, and usage notes. The customer's marketing or operations team rebuilds the templates in Salesforce's Email Template builder or Content Builder. This is documentation-only scope; no template records are created in Salesforce during migration.

MaxCredible's XML-based ERP integration for Oracle and SAP uses a proprietary schema that is not publicly documented. We request sample XML files from the customer's MaxCredible instance during discovery, reverse-engineer the schema, and document the field mappings for use in a Salesforce-native integration (MuleSoft Composer, Boomi, Jitterbit, or an AppExchange ERP connector). The integration rebuild itself is outside migration scope.

MaxCredible user accounts map to Salesforce User records. We extract name, email, and role assignment from MaxCredible. Roles migrate as Salesforce Role assignments, which the customer's admin configures in the Salesforce Role Hierarchy post-migration. Owners without a matching Salesforce User are held in a reconciliation queue for the admin to provision before record import resumes.