Reconcile the RTA statement against your own unit records.

What it does

The agent works on one fund per run. When you upload a statement PDF, it:

1. Checks fund readiness. Before looking at the statement at all, it checks whether every unit type your fund actually holds — with a real, non-zero balance — has an ISIN set up against it. A unit type with real commitments but no ISIN configured can never be reconciled, however good the statement is. This check exists to surface that gap up front rather than let it hide inside a clean-looking reconciliation.
2. Reads the statement. Extracts the text from the PDF and uses AI to pull out one entry per scheme, being each ISIN block: scheme name, ISIN, NAV, summary totals for opening, subscribed, redeemed and closing units, and a folio-by-folio breakdown of folio number, investor name, holding type, opening and closing units, and pending requests.
3. Reconciles each scheme found in the statement:
   • Summary check — the RTA's total closing units for that scheme against the total units CapHive has on record for that unit type.
   • Folio-level check — each folio's closing units on the statement against the matching investor record in CapHive, matched by folio number and unit type.
   • Movement check — the subscriptions and redemptions the RTA reports for the period against CapHive's own unit activity over the same dates. This only runs once a previous reconciliation exists for the fund, since it needs that prior run to know where the period started.
   • Opening balance continuity — that this period's opening balance as reported by the RTA matches the closing balance the RTA reported last time for the same folio. This catches discrepancies a closing-balance-only check could miss.
   • Investor name check — flags a folio where the folio number matches a CapHive record but the investor name on the statement differs from what is on file, ignoring case and extra spacing.
   • Reverse check — looks for investor holdings in CapHive with a real balance and a folio number that never appears anywhere in the statement.
4. Checks coverage fund-wide. Compares every ISIN your fund holds, properly configured and with a non-zero balance, against the ISINs this particular statement actually covered. This is the only check that can catch a scheme the AMC forgot to send entirely, since the per-scheme checks only ever look at ISINs the PDF mentions.
5. Flags pending requests. Folios where the statement shows an in-flight subscription or redemption request are flagged as warnings, not as mismatches.
6. Sends the report, optionally emailing the reconciliation summary.

Nothing is ever written back to your investor holding or unit activity records. This agent only compares and reports.

What it needs

Configuration fields

Setup warnings

The agent's General tab shows a yellow warning banner whenever setup would undermine a run. For this agent it flags:

• Both tolerance fields empty. With neither set, tolerance is zero and every minor rounding difference in the RTA PDF is reported as a mismatch, drowning real breaks in noise.
• “Email report after run” set to Yes with a blank Notify email — the report would never be emailed.
• Any unit type whose ISIN is not configured. A unit type with no ISIN on its fund unit settings cannot be matched to any scheme in the statement, so its folios are invisible to every check. The banner names each affected unit type and fund.
• Either Yes/No toggle that has never been given a value — an unset toggle counts as off, which silently skips that behaviour.

Other data inputs

• The RTA statement PDF, uploaded each time you run the agent through its dedicated upload window rather than the agent's normal configuration page. It is the only file input; there is no recurring or pre-attached statement, and every run needs its own fresh upload.
• Your fund's unit configuration, which provides the ISIN each unit type is matched against.
• Your fund's investor holding records. The unit count and folio number on file for each investor and unit type are the CapHive side of every comparison.
• Your fund's unit activity ledger, used only for the movement check.
• The previous reconciliation report, if one exists, stored automatically from prior runs. It anchors the movement check and the opening-balance continuity check — the very first run for a fund has neither available, so those two checks are skipped that time.

Turning it on

An administrator enables the agent with a feature toggle under Admin → Edit Entity → Support Agents. Because the agent uses AI to read the statement, your entity needs at least one AI provider key configured under AI → Support Agents → LLM Keys. There is also a per-agent AI Model setting on the agent's Edit page that, if filled in, overrides your entity's default model for this agent only.

The upload button that starts a run only appears once the feature toggle is enabled, and only for users with edit permission on the specific fund. Note for administrators: this agent is not assigned to one of the usual internal groupings, so on the agent index page it appears under Uncategorized.

Running it

There is no generic “Run Now” button. Running the agent always requires uploading a PDF, so it has its own dedicated upload window instead of the standard agent run screen.

1. Open the fund's show page.
2. If the feature is enabled for your entity and you have edit rights on the fund, a Run RTA Reconciliation action is available in the fund's action area.
3. The upload window asks for an RTA statement PDF — PDF files only. It is the only required field; there is no separate notes or context field.
4. Click Run Reconciliation.

The uploaded PDF is saved as a document on the fund, named “RTA Statement (PDF)”, before the reconciliation starts. That order works in your favour: the PDF stays on file even if the reading step later fails or has to be retried.

The agent always runs against the one fund you triggered it from — there is no run-for-every-fund option. Once you click Run, a live step-by-step progress panel appears: Initialize, Fund Readiness, Parse Statement, Reconcile, Coverage Check, Pending Requests, Send Report, Save Report.

Scheduling

Not supported. There is no default schedule and no recurring-run option for this agent. Reconciliation is inherently tied to a one-off statement upload, so you run it on demand each time a new statement arrives from your RTA.

Where the output goes

• Reconciliation History tab on the agent's own page, under AI → Support Agents → RTA Reconciliation. It lists every run across all of your funds, with a health score, scheme count and folio-mismatch count per run. Expanding a row shows the full coverage breakdown — fund-wide, then ISIN-configured, then covered by this statement — along with per-scheme detail, folio-level mismatches, pending requests, folios missing from the statement, opening-balance continuity issues and investor name mismatches.
• Email. If “Email report after run” is Yes and Notify email is filled in, an HTML summary goes to that address after each run. Per scheme it shows a banner with the mismatch count and an all-matched or health-score indicator, a summary table of RTA units against CapHive units and the difference, a folio mismatch table when any exist, pending-request callouts, and a callout listing CapHive folios missing from the statement entirely.
• Report history. A new report is saved on every run, tied to the fund. Older runs are never overwritten. A report is marked Failed when any serious issue was found and Completed otherwise.

Reading the result

• Health score — the percentage of checks that passed cleanly. Only clean passes and serious mismatches count towards it; warning-level issues such as pending requests, folios missing from the statement, name mismatches and continuity issues are excluded. A run with no real mismatches scores 100% even with advisory warnings attached.
• Scheme results — one entry per ISIN found in the statement: whether the summary matched, the per-folio match, mismatch or unmatched status with RTA against CapHive units and the difference, folios on file that are missing from the statement, folios with pending requests, and the movement comparison, or blank if there is no prior run to anchor the period against.
• Scheme coverage — every ISIN your fund holds, and whether this statement covered it at all.
• Unit readiness — every unit type with a real balance, and whether it even has an ISIN configured. This is the fund-wide readiness check, independent of any statement.
• Fund-wide rollup — a summary across three layers, each a subset of the one before it: every unit type the fund holds regardless of setup, the subset with an ISIN configured, and the subset this specific statement actually covered.

Where it can fail

• A folio only needs to pass one of the two tolerance checks, not both. A folio or summary is treated as a match if it is close enough on either an absolute basis or a percentage basis. With the default setup, percentage tolerance at 0, only the absolute tolerance is active. Turn on a percentage tolerance and a small fund with a sizeable percentage swing can still pass if the absolute unit gap is tiny, while a large fund with a tiny percentage swing can pass even with a fairly large absolute gap. If matching feels too loose, tighten whichever of the two is letting too much through.
• No PDF uploaded, or the PDF cannot be read. If no file was attached, or the file is empty, the run stops immediately with “No RTA statement PDF uploaded.” If the PDF has no readable text at all — a scanned image with no text layer, for example — the run stops with “Could not read text from the uploaded PDF.” There is no fallback that can read text out of an image-only scan.
• Non-standard statement dates. RTAs format dates inconsistently. The agent does its best to interpret whatever date it found; if that fails it falls back to storing the raw text, which then does not sort or compare reliably for the movement check. Use the Statement date override field to force the correct date.
• The statement could not be understood, or came back malformed. Both show up as a serious issue on the run — no scheme data found, or the response was not valid. A timeout or rate-limit hiccup from the AI provider is also caught and shown as a run issue rather than crashing the page.
• Orphan ISINs. If the PDF contains an ISIN that does not match any unit configuration on the fund, that whole scheme is skipped and shown as a warning rather than reconciled. Its folios and units are reported as orphan, but they are never actually checked against CapHive.
• Unconfigured unit types. A unit type with real, non-zero holdings but no ISIN set up at all is invisible to the per-scheme checks. The fund readiness check at the start of the run is the only thing that surfaces this, as a serious issue, regardless of what is in the statement you upload.
• Folios in the statement that do not exist in CapHive. These show up as mismatches needing attention. Common causes: a typo in the folio number on the AMC's statement, a folio predating your CapHive records, or a unit-type mix-up — the same folio number reused across two unit classes can resolve to the wrong investor record if the unit type does not line up.
• Pending-transaction false positives or negatives. The agent recognises the common ways an RTA phrases “nothing pending”: None, Nil, NA, N/A, Not Applicable, a dash, or blank. A statement that phrases it differently, such as Settled or Processed, could be misread as an actual pending request, or the reverse, if the extraction normalises it inconsistently.
• Movement and continuity checks need a prior run to compare against. The very first reconciliation for a fund has nothing to anchor against, so both checks are quietly skipped rather than flagged. Do not expect this detail until the second run onward for a given fund.
• A blank Notify email with “Email report after run” set to Yes. The email step is simply skipped, with no error and no warning raised on that run, so a blank recipient field looks identical to everything working fine.
• Running the agent twice in quick succession on the same fund. Each run creates a new report rather than locking the fund while it works, so two back-to-back uploads for the same fund can overlap. Whichever run finishes and is marked latest is what the next run anchors against, so overlapping runs can produce confusing movement and continuity results.
• Investor name mismatches do not block the run. They are shown only as warnings, even though they could point to a stale folio reassignment or two different investors sharing a folio number by coincidence.

Questions we get asked