Now A worked example of reconciling a revenue schedule, movement report and ledger before proposing a journal, with explicit checks for missing data and duplicate posting.
Claude can help compare reports and prepare a journal proposal when it can access the relevant files or tools. Retrieving reports directly and creating an entry in the accounting system depend on the connector, supported operations and permissions. Treat those as capabilities to verify in your own setup.
The useful workflow starts by establishing what the reports represent. Three files from the same system can use different entities, dates, currencies or accounting bases. Matching their totals without checking those settings can produce a plausible entry for the wrong period.
This guide follows a synthetic revenue-release example from source reports to a proposed journal. It is an arithmetic and review exercise, not a production posting or a recommendation about when a real contract's revenue should be recognized.
Define the accounting question first #
Assume an accountant has already determined the revenue-recognition policy and approved the underlying schedule for one test entity. The task is to prepare the remaining monthly release from deferred revenue into service revenue.
For this example:
- The period is October 2026 and all reports use the same cutoff.
- Document and functional currency are both EUR; there is no foreign-currency translation.
- The amounts exclude tax, and tax has already been dealt with in the underlying billing records.
- There are no refunds, contract modifications, reclassifications or other movements beyond those shown.
- The current period is open, and the scheduled release has not yet been posted.
These assumptions are part of the exercise. A real workflow needs an explicit policy for additional movements, currency, tax, materiality and review. Never use a generic rounding allowance to conceal an unexplained difference.
Read three reports with one scope #
The reports answer different questions:
| Source | Question | Value in this example |
|---|---|---|
| A: Approved recognition schedule | How much service revenue is due for release this month? | €12,000 |
| B: Deferred-revenue movement workpaper | What should the closing liability be after the release? | €72,000 credit |
| C: Ledger detail and control-account balance | What is actually posted before this proposed entry? | €84,000 credit |
Report B contains the following bridge, with liability balances shown as positive credit amounts:
| Movement | EUR |
|---|---|
| Opening deferred revenue | 60,000 |
| New billings already credited to deferred revenue | +24,000 |
| Scheduled release, not yet posted | −12,000 |
| Expected closing deferred revenue | 72,000 |
First check that the actual ledger before the release agrees with the recorded movements: €60,000 + €24,000 = €84,000. Then compare the scheduled release with the difference between the actual and expected closing balances: €84,000 − €72,000 = €12,000.
A table heading alone is insufficient evidence. Confirm that the workpaper's release is a scheduled amount, while the ledger report shows actual postings. If Report B instead contains only posted movements, it has a different meaning and this comparison must change.
Check whether the release already exists #
Before proposing an entry, inspect the relevant journal detail for the same entity, service period, contracts and schedule references. A balance difference is not a unique transaction identifier.
If the full €12,000 release is already posted, the ledger would be €72,000 under these assumptions. A second release would reduce deferred revenue to €60,000 and overstate service revenue by €12,000.
If €5,000 has been posted, the ledger would instead be €79,000. The remaining release could be €7,000, but only after matching that earlier posting to the same schedule. Do not derive a catch-up entry from the difference alone: unrelated corrections or a mismatched report scope can produce the same balance.
For each schedule line, retain a link or reference to its posting, or an explicit finding that it remains unposted. This makes a later rerun reviewable.
Prepare the proposal #
When the checks pass for the original example, the proposed journal is:
| Account | Debit EUR | Credit EUR |
|---|---|---|
| Deferred revenue liability | 12,000 | 0 |
| Service revenue | 0 | 12,000 |
| Total | 12,000 | 12,000 |
Use the entity's configured accounts and required dimensions. The labels above describe the example's account roles; they are not a universal chart of accounts. Include the posting date, entity, currency, schedule references, calculation and the reason the entry is needed. Attach or reference the source reports with their export timestamps and filters. A reviewer should be able to distinguish inputs, calculations and accounting decisions.
Here is a preparation-only instruction to adapt for a synthetic test:
Read the three supplied reports for the named test entity and October 2026 in EUR. Confirm their filters and distinguish scheduled amounts from posted movements. Reconcile opening balance, new billings, scheduled release and expected closing balance. Inspect existing journals for the same schedule and period. Show the reconciliation, source references and any remaining proposed entry. Stop on an unexplained difference or missing posting evidence. Do not submit a journal.
Use a spreadsheet formula, checked script or authoritative system calculation for the arithmetic. Keep the calculation with the proposal so it can be repeated.
Submit and verify as separate steps #
After reviewing the proposal, authorize any submission through the system's supported workflow. A draft, an approval request and a posted journal are different results. Capture the returned references and inspect the actual state.
Arfiti exposes accounting operations through shared tools and APIs. Financial submissions use the governed write path and applicable permissions, validation and approvals. An external assistant can supply the procedure; using a built-in agent is optional. Our controls overview explains that boundary.
For this example, read the saved journal and a fresh ledger report after posting. Check that the debit and credit are €12,000, the entity and period are correct, and deferred revenue closes at €72,000. Confirm the schedule's posting reference before considering the task complete.
If the submission times out, preserve its original identity and references. Investigate whether it committed before trying again. Duplicate protection on a request does not establish that a different request would be safe.
Include failure cases in the evaluation #
Run the example again with one deliberate change at a time:
| Changed input | Expected review outcome |
|---|---|
| One report uses a different entity or month | Stop and correct the scope |
| The release already exists | Explain the existing posting; propose no duplicate |
| A schedule line is absent from the report | Report incomplete evidence |
| An unexplained €200 movement appears | Investigate it before preparing the entry |
| The posting period is closed | Respect the system refusal; ask for the appropriate accounting decision |
These are proposed evaluation outcomes, not claims that this article ran a live integration test. Retain what your actual test produced, including refusals and unresolved cases.
To assess direct access, consult Anthropic's connector guidance and the documentation for your accounting system. A working read connection does not prove that journal submission is supported or authorized.
Tell us which reports and accounting workflow you want to evaluate. We are preparing to open access on 25 November; enquiries receive a personal reply and do not create an account.
Related reading: Claude for controllers, what happens in a billing run, and Claude accounting skills.