What breaks when a Rillet contract amendment isn't reflected in the revenue schedule?

Rillet's amend-a-contract endpoint requires an effective_from choice — AS_OF_AMENDMENT_DATE or END_OF_CURRENT_BILLING_CYCLE. If a workflow leaves this unset or picks the wrong one, the amendment is accepted successfully but doesn't change revenue recognition until the next billing cycle starts, which looks identical to a failed or dropped amendment until you check which option was actually sent.

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 contract amendment succeeds in Rillet but the revenue schedule looks unchanged
Root cause	effective_from was set to END_OF_CURRENT_BILLING_CYCLE (or defaulted there) instead of AS_OF_AMENDMENT_DATE
Not a sync bug	The amendment succeeded — it's deferred by design, not lost
Where to check	The effective_from value actually sent on the amend-a-contract call, not the revenue schedule itself

The field that decides when an amendment actually takes effect

Rillet's amend-a-contract endpoint takes an amendment_date, an amendment_reason, and the changed items, but a separate field — effective_from — decides when the change actually starts affecting billing and revenue: AS_OF_AMENDMENT_DATE applies it immediately as of the amendment date, and END_OF_CURRENT_BILLING_CYCLE delays it until the current billing cycle concludes. Both are legitimate, documented options, not an error state.

Rillet's own API reference is explicit that this field controls timing, but doesn't describe what happens downstream in revenue recognition when each option is chosen — that's left to how the workflow calling the endpoint is built. If a workflow doesn't pass effective_from explicitly, or passes it without understanding the difference, a mid-term upgrade or downgrade can be accepted and confirmed by Rillet while having zero visible effect on the current period's revenue schedule.

Why this looks like a bug and isn't

From the outside, a deferred amendment and a dropped one look identical: the revenue schedule for the current period doesn't change either way. The difference only shows up by checking what was actually sent on the amend-a-contract call, or by waiting for the next billing cycle to see the change apply. Rillet's amendment response returns an ExpandedContract object with the full updated contract, so the correct effective_from value is confirmable from the API response itself — the failure mode is a workflow that doesn't check it, not a Rillet limitation.

How to design around it

Always pass effective_from explicitly rather than relying on a default, and log the value alongside the amendment so a later "why didn't this change anything" question has an immediate answer. If the business rule is that upgrades take effect immediately and downgrades wait for the next cycle (a common pattern for proration reasons), encode that choice in the workflow rather than leaving it to whatever Rillet's default happens to be — a documented default can still change between API versions.

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 mid-cycle downgrade that looks ignored for three weeks

A customer downgrades on the 8th of a monthly billing cycle. The workflow calls amend-a-contract with the new, lower-priced item and effective_from=END_OF_CURRENT_BILLING_CYCLE — correct for a downgrade, since crediting mid-cycle would require a separate proration step. The amendment succeeds and Rillet returns the updated ExpandedContract. But the current period's revenue schedule, checked the same day, still shows the old, higher amount — because it's supposed to, until the cycle rolls over on the 1st. Without a log of which effective_from value was sent, this reads as a stuck or failed amendment for three weeks, prompting a support ticket that a five-second check of the original API call would have resolved.

Frequently Asked Questions

Treat it as required rather than relying on undocumented default behavior — Rillet's own reference documents it as an available option without specifying default behavior if omitted, and defaults are exactly the kind of thing that can change silently between API versions.

The documented workflow is a new amend-a-contract call, not an edit to a prior amendment — treat each amendment as its own event rather than something mutable after the fact.

No. A true sync failure means the amend-a-contract call itself errored or never reached Rillet. This is different: the call succeeds, Rillet confirms it, and the revenue impact is simply scheduled for later — the fix is checking the API response, not retrying the call.

Sources

Diagnostic

Why doesn't deferred revenue match the general ledger?

Deferred revenue usually drifts from the general ledger when the billing system's revenue schedule isn't synced to GL journal entries, or when manual entries post outside that schedule. Reconcile the deferred revenue roll-forward against the GL trial balance at the contract-line level, not the invoice level, to find exactly where the two diverge each month.

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 sync a Rillet contract amendment into my revenue recognition schedule?

Call Rillet's amend-a-contract endpoint with an amendment_date, an amendment_reason, and the changed items, choosing whether each item takes effect as of the amendment date or at the end of the current billing cycle. Rillet regenerates the affected revenue schedule and journal impact for review before anything posts.

Diagnostic

How do I account for a mid-contract upgrade under ASC 606?

It depends on two tests: are the added goods/services distinct from what's already delivered, and is the added price in line with their standalone selling price? Distinct-and-priced-right modifications become a separate contract; distinct-but-mispriced ones get prospective treatment; not-distinct modifications require an immediate cumulative catch-up adjustment.