In This Article

LedgerUp raises $500K in seed funding, led by Y Combinator

How to Sync Salesforce Contracts to Sage Intacct Invoices

Why most Salesforce-to-Intacct invoice syncs break — and how to design one that finance actually trusts.

Quick Answer

Most finance teams don't realize their Salesforce-to-Sage Intacct integration is broken until month-end. The invoices that posted don't match the contracts that closed. Line items are missing. A customer got created in the wrong entity. Someone on the AR team is spending two hours reconciling records that should have matched automatically, and no one can pinpoint when the data diverged.

This guide covers how to design a reliable Salesforce Sage Intacct integration for invoice sync — from choosing your billing source of truth to field mapping, sync cadence, and the finance controls that keep bad data out of your general ledger. It's written for finance ops, RevOps, and technical operators at B2B SaaS companies who need this workflow to hold up under real transaction volume.

To sync Salesforce contracts to Sage Intacct invoices reliably:

  1. Use Salesforce Contract activation as the billing trigger — not Opportunity Stage.
  2. Validate the customer record in Sage Intacct before attempting invoice creation.
  3. Map contract line items to ARINVOICEITEM fields including quantity, price, and service period dates.
  4. Store the 18-character Salesforce Contract ID as an external key on the Intacct invoice to prevent duplicates.
  5. Use scheduled or staged sync rather than triggering from mutable sales fields.

Most companies take one of two paths: sync Salesforce Contracts into Intacct Contracts and let Intacct's contract billing engine generate invoices, or sync directly to ARINVOICE for milestone or one-time billing. The right choice depends on your billing model.

Why the Salesforce-to-Sage Intacct Invoice Sync Breaks

Three categories of problems account for most sync failures.

Object ambiguity. Teams often disagree on whether the Opportunity, Contract, Order, or a custom object should trigger invoice creation. When no one explicitly owns that decision, the integration inherits conflicting assumptions from sales, finance, and engineering. A rep thinks "Closed Won" means the invoice should exist. Finance thinks it shouldn't post until contract terms are reviewed. The integration does whatever was coded first.

Weak trigger controls. Using a mutable field like Opportunity Stage as the billing trigger means invoices can fire when a rep updates a picklist, not when finance has approved the commercial terms. Sales stage reflects pipeline progression, not billing readiness. We've seen companies generate dozens of premature invoices in a single quarter because a rep toggled a deal back and forth across the Closed Won threshold during negotiations.

Duplicate handling gaps. Sage Intacct's AR invoice documentation warns that certain Order Entry transaction definitions recreate AR transactions and assign new RECORDNO values. If your integration uses Intacct record numbers as the sole cross-system key, a recreated transaction orphans your mapping and produces duplicates. This one is particularly painful because the duplicates look legitimate — they have different record numbers, so a naive dedup check passes them through.

What Salesforce Object Should Trigger Sage Intacct Invoices?

Before you touch a field mapping spreadsheet, your team needs to decide which Salesforce object is authoritative for billing. This is a business decision, not a technical one, and it needs to be made explicitly.

Why Opportunity Is Usually the Wrong Invoice Source

Opportunity is where sales manages pipeline, forecast, and deal context. Salesforce's object reference describes Opportunity as the record for managing information about a sale or pending deal — and "pending deal" is the operative phrase. Reps edit Opportunity fields throughout the pipeline. Amount changes during negotiation. Close date slips. Products get added and removed. The Opportunity can also sync with a child Quote, which adds another layer of data that may or may not reflect final terms. If your ERP reads from a record that's still in motion, your invoices will reflect whatever state the deal was in when the sync happened to run, not the final agreed terms.

Contract as the Billing Trigger

Once a deal closes, the Salesforce Contract object is often the better billing source. Salesforce Help confirms that contracts can be created from an Opportunity, Order, or Quote, with data copied from the parent object into the Contract record. The activation status on a Contract is a cleaner control point than Opportunity Stage because activation is deliberate and, in most orgs, irreversible.

Sage Intacct's own Salesforce integration documentation states that a Salesforce Contract must be activated before synchronization is attempted. The connector treats activation as the gate. If your process already requires contract activation before billing, the integration respects that workflow. If it doesn't, you now have a reason to add that step.

When Orders, Quotes, or Custom Objects Make More Sense

Not every org routes through Contract. CPQ-heavy teams may use Quotes as the source of line-level pricing. Others use Orders for fulfillment-triggered billing or custom subscription objects for usage-based models.

The object doesn't matter as much as the decision. Pick one as the billing source of truth, document it, and make sure sales, finance, and engineering all agree. Every ambiguity you leave here will eventually surface as a sync failure.

Should You Sync Into Intacct Contracts or Directly to AR Invoices?

This is a design decision that many teams skip over, and it causes confusion downstream. When you sync from Salesforce into Sage Intacct, you can target two different object paths, and each one has different implications for record lifecycle, control, and reconciliation.

Syncing Through Intacct Contracts

Sage Intacct's native Salesforce connector is designed around this path. It uses Salesforce Contracts (along with their associated Opportunities and Opportunity Products) to create and manage Intacct Contract records. The integration documentation confirms that Salesforce Contracts and their opportunities are used to create Intacct Contracts, and that contract invoices generated in Intacct are then mirrored back to Salesforce as read-only custom objects for sales and CS visibility.

This path works well when your billing model aligns with Intacct's contract billing engine — recurring subscriptions, scheduled invoicing, and standard revenue recognition. Intacct manages the invoicing schedule, and the AR invoices are created by the contract billing process rather than by your integration directly.

The key constraint: contract invoices mirrored back into Salesforce are read-only. Salesforce serves as a reference view, not the correction path. If an invoice needs adjustment, that happens in Intacct.

Syncing Directly to AR Invoices

Some teams bypass Intacct Contracts and write directly to the ARINVOICE object. This gives you more control over invoice timing, line-item composition, and document formatting, but it also means you own the entire invoice lifecycle in your integration logic. You're responsible for duplicate prevention, service period handling, and any revenue deferral setup that Intacct's contract billing engine would otherwise manage.

Direct AR invoice sync makes sense for one-time invoices, milestone billing, or billing models that don't fit neatly into Intacct's contract framework.

Comparison: Intacct Contracts vs. Direct AR Invoice Sync

ApproachBest ForAdvantagesTradeoffsSalesforce → Intacct ContractsRecurring SaaS billing, annual subscriptionsAutomated invoice scheduling, built-in revenue deferral, standard connector supportLess control over invoice timing and formattingSalesforce → ARINVOICE directlyMilestone billing, one-time invoices, non-standard modelsFull control over invoice lifecycle and line-item compositionMust manage duplicate prevention, deferral, and scheduling in integration logicMiddleware orchestration (Workato, Celigo, etc.)Complex multi-entity billing, conditional routingTransformation logic, validation layers, retry handlingAdditional system to maintain and monitor

Make this decision explicitly before you start building. It affects your field mapping, duplicate prevention strategy, reconciliation approach, and how much billing logic lives in Intacct versus in your integration layer.

Core Objects on Both Sides of the Integration

A standard sync design touches objects on both sides that need to be understood before mapping work begins.

Salesforce Objects

Account maps to the Sage Intacct customer record. Billing address, entity, currency, payment terms, and tax identifiers all originate here. If Account data is incomplete, invoice creation will fail downstream — and it will fail silently if your integration doesn't validate before pushing.

Opportunity provides commercial context: deal amount, close date, owner, and stage. Opportunity Products (line items) carry the product, quantity, price, and term details that may feed invoice lines or Intacct Contract lines.

Contract holds the signed terms, effective dates, and activation status. Quote and Order may also carry relevant pricing and schedule data. Custom fields for billing start date, billing frequency, legal entity, or invoice grouping logic are common additions — if your org uses any of these, they need to be part of your mapping plan from day one.

Sage Intacct Objects

CUSTOMER is foundational. Sage Intacct's customer documentation describes the customer record as the entity to which invoices are attached, with fields that drive tax behavior, address printing, and entity assignment. The customer record isn't just a name and address — it determines which entity the invoice posts to, how sales tax is calculated, and what prints on the invoice itself. A missing or misconfigured customer record blocks invoice creation entirely.

ARINVOICE is the core receivable record. It includes header fields (customer reference, invoice date, due date, document number, currency, status) and line-level details (item or GL coding, description, amount, quantity, service period, tax treatment). If you're syncing through Intacct Contracts, the contract billing process creates these AR invoices for you. If you're syncing directly, you write to this object yourself.

The MODULEKEY filter deserves special attention. Because RECORDNO values can change when AR transactions are recreated from Order Entry, filtering by module or source context when running reconciliation queries is safer than relying on Intacct's internal record numbers. If you build reports or API queries that use RECORDNO as the primary lookup, you're building on unstable ground.

Salesforce to Sage Intacct Invoice Field Mapping

Sage Intacct's field mapping documentation states that data sync uses a one-to-one relationship between fields. Multiple Salesforce fields cannot map to a single Intacct field, and if an Intacct field is inactive, the mapping silently fails. These constraints mean you may need formula fields or Salesforce automation to concatenate or derive values before sync, rather than expecting the integration layer to combine them.

One additional nuance from the connector documentation: standard mappings can be overridden with custom field mappings for Accounts, Contacts, Contracts, and Contract lines, but required Intacct fields cannot be overridden. If Intacct requires a field for invoice or customer creation, your Salesforce data model must supply a value — there's no way to work around it in the mapping layer.

Customer and Account Mapping

Salesforce Field Sage Intacct Field Notes
Account Name CUSTOMER.NAME Must match or create before invoice sync
Billing Address CUSTOMER.BILLTO Full address block; drives invoice printing
Currency (ISO Code) CUSTOMER.CURRENCY Required for multi-currency orgs
Payment Terms (custom or standard) CUSTOMER.TERMNAME Net 30, Net 60, etc.
Tax ID / VAT Number CUSTOMER.TAXID Required for tax compliance; drives tax calculation
Entity / Subsidiary CUSTOMER.LOCATIONID Drives entity-level posting and tax behavior

Customer records must be created or validated in Intacct before any invoice sync runs. If your integration attempts to create an invoice for a customer that doesn't exist, the transaction fails. Treat customer validation as step zero — not step one.

Invoice Header Mapping

Salesforce Field Sage Intacct Field Notes
Contract Number ARINVOICE.DOCNUMBER or external ref Stable cross-system identifier
Contract Start Date / Billing Date ARINVOICE.WHENDUE (derived) Used to calculate due date with terms
Invoice Date ARINVOICE.WHENCREATED Date the invoice should post
Currency ARINVOICE.CURRENCY Must match customer currency
Billing Entity ARINVOICE.LOCATIONID For multi-entity posting

Invoice Line Mapping

Salesforce Field Sage Intacct Field Notes
Product Code / SKU ARINVOICEITEM.ITEMID Or GL account if no item master
Description ARINVOICEITEM.MEMO Line-level description
Quantity ARINVOICEITEM.QUANTITY Units billed
Unit Price ARINVOICEITEM.PRICE Per-unit amount
Service Period Start ARINVOICEITEM.STARTDATE Required for Rev Rec / deferral
Service Period End ARINVOICEITEM.ENDDATE Required for Rev Rec / deferral
Discount ARINVOICEITEM.DISCOUNT or derived Apply before or after tax
Tax Code ARINVOICEITEM.TAXENTRIES If tax is line-level

Why Service Period Fields Matter for Revenue Recognition

The STARTDATE and ENDDATE fields on invoice lines aren't optional metadata — they drive revenue deferral in Sage Intacct. Under ASC 606 and IFRS 15, revenue from a SaaS subscription must be recognized over the service period, not at the point of invoicing. If these fields are missing or wrong, Intacct either recognizes the full invoice amount immediately (overstating revenue in the current period) or can't generate a deferral schedule at all.

For annual subscriptions invoiced upfront, this is the difference between a clean close and a manual journal entry every month. If you're syncing through Intacct Contracts, the contract billing engine handles much of this automatically — but only if the service dates on the source records are accurate. If you're syncing directly to AR invoices, you own the deferral setup entirely.

How to Handle Multi-Currency Billing in the Sync

If your company invoices in multiple currencies, the currency on the Salesforce Contract and the currency on the Intacct customer record must match. A mismatch will either block the invoice or post it in the wrong currency. Intacct uses exchange rate types (daily, fixed, or custom) to handle currency conversion for reporting, but the transactional currency on the invoice must be set correctly at creation time — it cannot be changed after posting.

Map the ISO currency code from Salesforce to ARINVOICE.CURRENCY explicitly, and make sure your customer records in Intacct have their default currency set to match the contracting currency, not your reporting currency. For companies selling internationally, this is one of the most common silent failure modes: the invoice posts, the amount looks right, but the currency is wrong, and the error doesn't surface until FX reconciliation.

Control and Audit Fields

These fields don't appear on invoices but are critical for operational reliability.

Field Purpose
Salesforce Contract ID (18-char) External ID / idempotency key in Intacct
Sync Status Tracks whether the record synced, failed, or is pending
Last Sync Timestamp For debugging and reconciliation
Approval State Finance-controlled flag indicating billing readiness
Exception Reason Captures why a sync failed (validation error, missing customer, etc.)

Should Salesforce Sync to Sage Intacct in Real Time or Batch?

Not every field should sync in real time. Operational fields in Salesforce change frequently as reps update deals, while posted accounting records in Intacct should be tightly controlled. The principle: sync commercial intent early, but sync accounting impact only after validation and approval.

Real-Time (Event-Driven) Sync

Event-driven sync — triggered by a Salesforce Platform Event, Change Data Capture, or webhook — makes sense when invoice creation must happen immediately after contract activation. The prerequisite is that all upstream validation (customer existence, required fields, approval flags) is already complete before the event fires. Without those controls, real-time sync just creates bad invoices faster.

Scheduled (Batch) Sync

Batch processing on a fixed cadence (every 15 minutes, hourly, or daily) gives finance a buffer. A scheduled job can query for billing-ready contracts, validate required fields, check for existing Intacct records, and push a clean batch. Salesforce's integration patterns documentation recommends deliberate pattern selection based on business requirements, and for most growing SaaS companies, scheduled sync is the safer default because it reduces error surface area and gives you a window to catch problems before they hit the ledger.

Hybrid (Staged) Sync

A staged approach often works best in practice. When a Salesforce Contract is activated, the integration creates a staging record or sync request. An automated validation layer checks required fields, customer status, and approval flags. Only after validation does the integration post the invoice to Intacct. Finance gets visibility into the queue without needing to manually push every invoice, and the system catches data quality issues before they become accounting problems.

Finance Controls That Prevent Duplicate or Bad Invoices

Integration architecture is only half the problem. The other half is governance: who can trigger an invoice, what stops duplicates, and what happens when something fails.

Billing-Ready Approval Gates

Contract activation is a good starting gate, but it's not always sufficient. Some teams add a billing-ready checkbox controlled by finance ops, separate from the sales-controlled contract status. Sage Intacct's Salesforce integration documentation notes that only designated Opportunity record types should feed contract creation, and organizations can configure which record types are eligible on the Intacct configuration page in Salesforce. If your org has multiple Opportunity record types (renewals, expansions, professional services), only the types that represent billable transactions should trigger the sync. Letting non-billable record types leak into the sync pipeline is one of the most common sources of phantom invoices.

Duplicate Prevention and Idempotency

Store the Salesforce Contract ID (the full 18-character version) as an external key on the Intacct invoice record. Before creating a new invoice, the integration should check whether a record with that key already exists. Because Intacct's RECORDNO can change when AR transactions are recreated from Order Entry flows, the Salesforce-originated external ID is the more stable anchor for deduplication.

Idempotency means that if the same sync request runs twice — due to a retry, timeout, or queue replay — the result is the same: one invoice, not two. Design your write logic to check-then-create or use upsert patterns where supported. For scheduled syncs especially, a batch that partially completes and then retries can easily double-post if the write logic isn't idempotent.

Exception Handling and Retries

Separate retryable failures (API timeouts, rate limits, temporary service unavailability) from non-retryable failures (missing required field, invalid customer, rejected validation rule). Retryable errors should go back into the queue with exponential backoff. Non-retryable errors should land in an exception queue visible to finance ops, with the error reason, source record link, and failed payload attached.

The distinction matters operationally: retrying a non-retryable error wastes cycles and obscures the real problem, while failing to retry a transient error creates gaps in your invoice coverage that you won't notice until reconciliation.

Audit Trail and Reconciliation

Every sync attempt should be logged with the source record ID, payload version, timestamp, and result (success, failure, or skipped). A weekly reconciliation report that compares billing-eligible Salesforce Contracts to posted Intacct invoices will catch drift before it becomes a close-cycle problem.

Contract invoices mirrored back from Intacct into Salesforce are read-only — this is by design. Salesforce serves as a reference view for sales and CS teams, but corrections to posted invoices must happen in Intacct. If your team isn't clear on this, someone will eventually try to "fix" an invoice in Salesforce and wonder why nothing changes in the ERP.

Automating the Salesforce-to-Sage Intacct Billing Workflow

How you implement the sync matters almost as much as what you sync. There are three broad approaches.

Sage Intacct's native Salesforce connector handles standard field mapping and contract-to-invoice sync out of the box. It works well for straightforward billing workflows where the one-to-one mapping constraint isn't a blocker and your Salesforce data model doesn't require heavy transformation. The tradeoff is limited flexibility: custom logic, conditional mapping, and multi-step orchestration are harder to implement within the connector's framework.

Middleware platforms (Workato, Boomi, Celigo, and similar) sit between Salesforce and Intacct and handle data transformation, conditional routing, error handling, and retry logic as configurable workflows. They fit when your billing logic requires steps the native connector doesn't support — multi-entity routing, conditional line-item mapping, or pre-sync validation against external systems. The tradeoff is cost and maintenance: another system to monitor, another vendor to manage.

AI-powered contract-to-cash automation takes a different approach entirely. Rather than building and maintaining a sync pipeline between Salesforce and Intacct, a platform like LedgerUp uses an AI agent to read signed contracts, extract billing terms, generate invoices in Sage Intacct, and reconcile CRM and ERP records automatically. Finance teams operate from a contract-level billing workflow while Sage Intacct remains the system of record for AR. For B2B SaaS companies that don't want to staff a dedicated integration engineer or manage middleware, this replaces the fragile sync pipeline with an intelligent layer that validates data before it reaches the ledger.

Common Implementation Mistakes

Using Sales Stage as the Billing Trigger

Opportunity Stage is a sales management field. Reps move deals forward and backward throughout the pipeline, and "Closed Won" doesn't guarantee that billing terms, customer data, or line items are complete. A dedicated activation or approval control — on the Contract or via a custom billing-ready flag — is more reliable because it represents a deliberate finance action rather than a sales workflow artifact.

Not Validating Intacct Field Activation Before Go-Live

If an Intacct field is set to inactive, it won't receive synced data even if the mapping exists. The sync doesn't throw an error — it silently skips the field. Teams discover this when they realize an entire column of data has been blank for weeks. Validate field activation status in Intacct before go-live, not after your first batch runs.

Mapping Without Accounting for One-to-One Constraints

The one-to-one mapping constraint in the Sage Intacct Salesforce connector means you can't combine two Salesforce fields into one Intacct field at sync time. If your invoice description needs to include both product name and service period, you need a formula field or process builder automation in Salesforce that concatenates those values before the sync reads them. Teams that skip this step end up with incomplete data in Intacct or resort to manual cleanup after every batch.

Ignoring Customer Master Data Quality

Invoice creation depends on a valid, complete customer record in Intacct. If the Salesforce Account is missing a billing address, entity assignment, currency, or payment terms, the invoice sync will fail at the customer lookup or creation step. Run customer validation before invoice creation in every sync cycle, and surface customer data gaps to whoever owns Account hygiene in Salesforce. The fix is always cheaper before the sync runs than after.

Salesforce → Sage Intacct Invoice Sync: Step-by-Step Architecture

Here is how a production-grade contract-to-invoice sync typically flows:

Salesforce Opportunity → Closed Won
       │
       ▼
Salesforce Contract created (from Opp, Quote, or Order)
       │
       ▼
Finance reviews and activates Contract
       │
       ▼
Integration validation layer
 ├─ Customer exists in Intacct?
 ├─ Billing-ready flag set?
 ├─ Required fields populated?
 └─ Service period dates present?
       │
       ▼
Create or update CUSTOMER in Sage Intacct
       │
       ▼
Create ARINVOICE + ARINVOICEITEM
(or sync to Intacct Contract for contract billing)
       │
       ▼
Invoice posts to Accounts Receivable
       │
       ▼
Invoice mirrors back to Salesforce (read-only)
       │
       ▼
Exception queue catches failures
 ├─ Retryable → back to queue with backoff
 └─ Non-retryable → finance ops review
       │
       ▼
Weekly reconciliation: Salesforce Contracts ↔ Intacct invoices

The sequencing is deliberate: sync commercial data (customer records, contract metadata) early, but sync accounting impact (invoice posting) only after validation and approval have passed.

Pre-Launch Checklist

Use this before going live with your Salesforce-to-Sage Intacct invoice sync.

Source of truth and sync target

  • Defined which Salesforce object (Contract, Order, or custom) is authoritative for billing
  • Decided whether sync targets Intacct Contracts (with contract billing) or AR Invoices directly
  • Confirmed that only designated Opportunity record types feed contract or invoice creation
  • Verified that Salesforce Contract activation is required before sync

Field mapping

  • Mapped customer/account fields with required Intacct fields (entity, currency, terms, tax)
  • Mapped invoice header and line fields with attention to one-to-one constraints
  • Created formula or automation fields in Salesforce for any values that need concatenation
  • Confirmed all mapped Intacct fields are active (inactive fields silently skip)
  • Verified service period dates (STARTDATE/ENDDATE) map correctly for revenue deferral
  • Confirmed required Intacct fields have values — these cannot be overridden by custom mappings

Customer data

  • Customer creation or validation runs before invoice creation in every sync cycle
  • Billing address, entity, currency, and payment terms are required on Salesforce Account before sync
  • Multi-currency customers have matching currency codes between Salesforce and Intacct

Sync cadence and triggers

  • Chosen cadence (real-time, scheduled, or hybrid) based on finance team's risk tolerance
  • Billing-ready flag or contract activation is the trigger, not sales stage

Duplicate prevention

  • Salesforce Contract ID (18-char) stored as external key on Intacct invoice
  • Integration uses check-then-create or upsert logic to prevent duplicate invoices
  • Not relying solely on Intacct RECORDNO as cross-system key

Error handling and monitoring

  • Retryable and non-retryable errors routed to separate handling paths
  • Exception queue visible to finance ops with error reason and source record link
  • Retry policy includes exponential backoff for transient failures

Audit and reconciliation

  • Every sync attempt logged with source ID, timestamp, payload version, and result
  • Reconciliation report compares billing-eligible Salesforce records to posted Intacct invoices
  • Defined ownership for reviewing exceptions and reconciliation gaps weekly

Testing

  • End-to-end test with a real Contract through activation, customer sync, invoice creation, and mirror-back
  • Tested with missing required fields to confirm validation errors surface correctly
  • Tested retry behavior with simulated API failures
  • Confirmed read-only behavior of mirrored invoice data in Salesforce
  • Verified inactive field detection before first production batch

FAQ

Can Salesforce sync directly with Sage Intacct without middleware?

Yes. Sage Intacct offers a native Salesforce connector that handles standard contract-to-invoice sync, including field mapping and contract activation gating. It works for straightforward billing workflows. For more complex scenarios — conditional routing, multi-step validation, or custom transformation logic — you'll need either middleware or an AI-powered accounts receivable platform like LedgerUp that handles the entire contract-to-cash workflow without requiring you to build or maintain the integration pipeline.

What triggers invoice creation in Sage Intacct from Salesforce?

In most well-designed setups, Salesforce Contract activation is the trigger. The native Intacct connector requires contract activation before sync, and only Opportunities with designated record types feed the process by default. Using Opportunity Stage (like "Closed Won") as the trigger is a common mistake — it's a sales management field that reps change frequently, and it doesn't guarantee billing readiness.

How do I prevent duplicate invoices when syncing Salesforce to Sage Intacct?

Store the full 18-character Salesforce Contract ID as an external key on the Intacct invoice record. Before creating a new invoice, check whether a record with that key already exists. Don't rely on Intacct's RECORDNO as your deduplication key — it can change when AR transactions are recreated from Order Entry flows. Design your write logic to be idempotent so that retries produce the same result, not additional invoices.

What happens if the customer record doesn't exist in Sage Intacct when the invoice syncs?

The invoice creation fails. Your integration should always validate (or create) the customer record in Intacct before attempting to post an invoice. Customer sync must run as a prerequisite step, not in parallel with invoice sync, because the customer record determines entity assignment, tax behavior, and address printing on the invoice itself.

Should I sync into Intacct Contracts or directly into AR invoices?

It depends on your billing model. If you have recurring subscriptions with standard scheduling and revenue deferral, syncing through Intacct Contracts lets the contract billing engine handle invoice generation, scheduling, and deferral automatically. If you have one-time invoices, milestone billing, or billing models that don't fit Intacct's contract framework, syncing directly to ARINVOICE gives you more control but also more responsibility for the entire invoice lifecycle.

How should multi-currency invoices be handled in the Salesforce-to-Intacct sync?

The currency on the Salesforce Contract and the Intacct customer record must match. Map the ISO currency code to ARINVOICE.CURRENCY explicitly. Intacct handles exchange rate conversion for reporting, but the transactional currency must be correct at invoice creation time — it cannot be changed after posting.

Do I need to map service period dates for SaaS invoices?

Yes, if you have any subscription or term-based revenue. The STARTDATE and ENDDATE fields on invoice lines drive revenue deferral in Intacct under ASC 606 and IFRS 15. Without them, Intacct either recognizes the full amount at invoicing or can't generate a deferral schedule — both of which are wrong for annual or multi-year SaaS contracts.

What happens if an Intacct field is inactive but still mapped?

The sync silently skips the field. No error is thrown, no warning is logged. The data simply doesn't arrive in Intacct. This is one of the most common reasons teams discover missing data weeks after go-live. Always verify field activation status in Intacct before your first production sync.

Publishing note: When publishing this article, add FAQPage, HowTo, and TechArticle schema markup (JSON-LD) to improve structured data signals for AI search systems and featured snippets.

What This Comes Down To

The companies that get this sync right aren't the ones with the most sophisticated integration architecture. They're the ones that made two decisions early: which Salesforce object is authoritative for billing, and whether to sync through Intacct Contracts or directly to AR invoices. Everything else — the field mapping, the cadence, the error handling — follows from those two choices.

The companies that struggle are usually the ones where sales, finance, and engineering each assumed someone else owned the billing trigger decision, and the integration quietly inherited all three assumptions at once. By the time anyone notices, there are duplicate invoices, missing service dates, and a controller spending the first three days of every month reconciling records that should have matched automatically.

Start with the Contract activation gate. Validate customer data before every sync cycle. Use the 18-character Salesforce ID as your cross-system key. And spend more time on your exception handling and reconciliation reporting than on the field mapping — the mapping is the part that works on day one. The monitoring is the part that keeps it working on day ninety.

Book a LedgerUp Demo

GET STARTED

Smart billing starts here

See how LedgerUp brings your billing and revenue systems into one place so you can remove busywork and focus on growth.
Book a demo

Ready to take manual work out of billing and revenue workflows?

See how LedgerUp brings your billing and revenue systems into one place so you can remove busywork and focus on growth.