What breaks when a Sage Intacct ArPayment goes unapplied?

If createArPayment is called with a RECORDKEY that no longer matches an open invoice line — the invoice was already partially paid, voided, or the line was adjusted between lookup and the call — the payment can be recorded without applying to anything. Cash arrives, but the invoice still shows as open and an unapplied balance sits on the customer's account instead.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 14, 2026Last reviewed September 14, 2026Editorial policy

Part of the finance integrations guide.

Symptom	A payment is recorded in Sage Intacct but the target invoice still shows an open balance
Root cause	The RECORDKEY (or ENTRYKEY, for a line-level payment) no longer matches the invoice state at the time createArPayment was called
Common triggers	The invoice was partially paid or adjusted between when it was looked up and when the payment call ran; a stale RECORDKEY was reused from an earlier lookup
Where it shows up	An unapplied cash balance on the customer's AR account, separate from any specific invoice

How a payment ends up unapplied instead of rejected

createArPayment applies a payment against whatever RECORDKEY (and optionally ENTRYKEY) it's given. If that reference no longer matches the invoice's current state — because the invoice was already paid down by another payment, voided, or an ENTRYKEY-targeted line was itself adjusted — Sage Intacct doesn't necessarily reject the whole call outright. Depending on how the mismatch happens, the payment can still be recorded against the customer, just without successfully applying to the specific line it was meant for, leaving it sitting as unapplied cash instead.

Why this is a timing problem, not a data problem

The RECORDKEY a workflow uses to call createArPayment usually comes from an earlier lookup — the invoice was queried, its RECORDKEY captured, and the payment call made some time later. If anything changes the invoice's balance or line structure in that window — a different payment posts, someone voids and reissues the invoice, a credit memo is applied — the RECORDKEY captured at lookup time can point at an invoice state that no longer exists by the time the payment call actually runs. The longer the gap between lookup and payment, and the higher the invoice volume, the more often this window gets hit.

How to find and fix it

Compare the customer's unapplied cash balance against payments the workflow believes it successfully applied — a payment the workflow logged as applied but that shows up in Sage Intacct's unapplied balance instead is exactly this failure mode. The fix for an individual case is to re-apply the unapplied payment against the invoice's current RECORDKEY, looked up fresh rather than reused. The systemic fix is to re-look up the invoice's RECORDKEY immediately before calling createArPayment rather than caching it from an earlier step, shrinking the window where the invoice can change underneath the call.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Worked example

A $2,750 payment that landed unapplied because of a stale RECORDKEY

A workflow looks up an open $2,750 invoice at 9:00am and captures its RECORDKEY. At 9:04am, a separate manual payment of $1,200 is posted against that same invoice directly in Sage Intacct, dropping its balance to $1,550. At 9:06am, the workflow's own createArPayment call fires using the RECORDKEY captured at 9:00am, attempting to apply the full original $2,750 — but the invoice's actual remaining balance is only $1,550. The result: $1,550 applies to close the invoice, and the remaining $1,200 lands as an unapplied credit on the customer's account instead of erroring, because the payment amount and the invoice's current state no longer agreed.

Frequently Asked Questions

Not reliably — depending on how the invoice changed, the payment can still be recorded against the customer without cleanly applying to the specific line it targeted, which is what produces an unapplied balance instead of an error.

Compare the customer's unapplied cash balance in Sage Intacct against the payments a workflow logged as successfully applied — a mismatch between the two is this failure mode.

It shrinks the window significantly but doesn't eliminate it entirely — a change could still land in the gap between the fresh lookup and the payment call itself, just a much smaller one.

Sources

Topic

AR & Collections

Accounts receivable is the money customers owe a business for goods or services already delivered on credit — a current asset on the balance sheet until it's collected. AR and collections, as a practi…

Diagnostic

How do I handle partial payments and split invoices in cash application?

Apply a partial payment against the specific invoice the customer intended, leaving the remainder open rather than closing the invoice or creating an unexplained credit. When one payment is meant to cover multiple invoices (a split payment), allocate it line by line using the remittance detail; if no allocation is specified, apply oldest-invoice-first is the most common default rule.

Topic

Integrations

Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…

How-to

How do I set up Sage Intacct AR payment application?

Loopfour's Sage Intacct integration has a dedicated createArPayment action, separate from createApPayment, that applies an incoming customer payment against an invoice by its RECORDKEY. When a payment doesn't cover the full invoice, Sage Intacct applies it using the waterfall method — one unpaid line at a time, starting with the first — rather than splitting it evenly.