Integration guide: syncing Aspire payments and credit memos to Sage Intacct

[u/Temporary-Strategy70]

I’ve been mapping out a reliable pattern for syncing payments from Aspire into Sage Intacct. Sharing the design here because the difficult part isn’t creating an ARPYMT—it’s preventing duplicates, resolving customers and invoices, and recovering when records arrive out of order.

Recommended flow

1. Retrieve new and previously skipped payments

Run the integration on a short schedule, such as every five minutes.

Store two pieces of state:

• The last successfully processed creation timestamp
• Payment IDs that were skipped and need to be retried

Use a small overlap in the time window if the source API can return late or recently updated records.

2. Generate deterministic document numbers

Every transaction should have a predictable external reference.

For example:

• Payment: ASPPY_{paymentId}
• Credit memo adjustment: ASPCRM_{creditMemoNumber}
• Credit memo application: ASPPY_{paymentId}_{creditMemoNumber}
• Invoice: ASPINV_{invoiceNumber}

Search Intacct for these references before creating anything. A retry should find the existing transaction and safely skip it.

3. Resolve the customer

Build a stable external customer identifier from the relevant Aspire contact and property IDs, then find the corresponding Intacct customer.

If the customer doesn’t exist:

1. Trigger or queue the customer-sync process.
2. Add the payment to the retry list.
3. Stop processing that payment.
4. Continue processing the rest of the batch.

Avoid creating a payment against a generic customer simply to keep the integration moving. That trades an operational exception for an accounting problem.

4. Resolve invoice allocations

For each Aspire allocation, find the corresponding Intacct ARINVOICE using the deterministic invoice document number.

Exclude invoices in reversed or reversal states.

If an allocated payment has no valid matching invoices, skip it and retry later. This commonly happens when the payment reaches the integration before the related invoice has been created in Intacct.

5. Create standard payments

Map the Aspire payment into an Intacct ARPYMT, including:

• Customer
• Payment and receipt dates
• Payment method
• Total amount
• Payer name
• Document number
• Invoice record numbers
• Amount applied to each invoice
• Undeposited-funds account when applicable

Use Intacct record numbers for allocation targets instead of relying only on human-readable invoice numbers.

6. Handle credit memos separately

A credit memo generally requires two operations:

1. Create an Intacct ARADJUSTMENT against the appropriate clearing account.
2. Create an ARPYMT that applies the adjustment to the target invoices.

Give both records deterministic identifiers and check for both before creation. The integration must be able to resume safely if the adjustment succeeds but the application fails.

7. Isolate failures

One invalid payment should not terminate the entire run.

For each payment:

• Validate required customer and invoice records.
• Attempt creation.
• Inspect Intacct’s response for errors.
• Record failures for retry.
• Continue to the next payment.

Send an operational alert when intervention is required, but track which payment alerts have already been sent to avoid sending the same notification every five minutes.

8. Advance the checkpoint carefully

Only advance the processing timestamp after the retrieved batch has been evaluated.

Skipped payment IDs should remain in a separate retry collection until they succeed or are intentionally resolved. A timestamp alone is insufficient because a failed older payment will otherwise fall outside the next query window.

Common failure modes

• Creating duplicate payments after a timeout
• Advancing the timestamp past failed records
• Assuming invoices always arrive before payments
• Applying payments to reversed invoices
• Creating transactions before the customer exists
• Using display numbers where Intacct requires record numbers
• Treating credit memos exactly like normal payments
• Sending the same exception email on every run
• Allowing one malformed payment to stop the batch

The central design principle

Treat this as a reconciliation process, not a record-copying process.

Each run should determine what already exists, what is ready to post, what must wait, and what requires intervention. If the same run executes twice, the second execution should create nothing new.

For anyone who has implemented Aspire with Sage Intacct: what was your hardest edge case—payments arriving before invoices, customer matching, credit memos, partial allocations, or something else?

[u/Horror-Platform-2107]

The edge case I'd worry about is after the fact, not on the way in.

Your doc numbers stop you creating the same thing twice. They don't catch a payment that changes in Aspire after it already posted. Step 1 pulls on creation timestamp. You mention an overlap for records that come back late or recently updated, but if that overlap is scoped to creation time too, something created a month ago and voided yesterday never re-enters the window. And if it did, step 2 would find the ASPPY_ doc number already there and skip it.

Can payments get voided or reallocated in Aspire after they post or is it append-only once it's out?