ACNC Charity Register Delta

Watches the official ACNC Register of Australian charities (data.gov.au, package acnc-register) by state/territory and reports only genuine changes since your last check: a new charity registration, or a confirmed deregistration. Free when nothing changes — you pay only for delivered events.

Built for compliance teams, grant-makers and donors who need to know when a charity in their book of business gets newly registered — or drops off the register — without re-downloading and diffing a 14+ MB CSV every week themselves.

Honest limits — read this before you rely on the signal

• The source itself updates weekly, not continuously. This is not a real-time feed.
• The register file carries no status field at all. ACNC does not publish "revoked"/"active" — a deregistered charity simply stops appearing in the next weekly file. This actor's entire signal is therefore presence/absence of an ABN between two snapshots, not a stated reason for the change. There is no "reason for deregistration" field to report, because the source does not provide one.
• ~0.9% of rows have no usable ABN (mostly Private Ancillary Funds that are legitimately not required to publish one). Those rows have no stable identity and are excluded from delta detection entirely — they never appear as appeared/disappeared, in any watch, including state: "ALL".
• The source's own State field is free text, not a clean enum: alongside the 8 canonical state/territory codes it contains inconsistent case, stray spaces, and outright garbage entries, plus ~10% blank values. Only rows whose State normalizes exactly to one of NSW/VIC/QLD/WA/SA/TAS/ACT/NT are matched by a state-specific watch; everything else (including blanks) is only visible under state: "ALL".
• Deregistration (disappeared) detection needs two consecutive complete weekly snapshots without the ABN (two-strike) — a single missing week only produces an unpaid removal_candidate row. Given the weekly cadence, a confirmed disappeared event lags the real-world change by roughly two weeks.
• If this run's CSV download looks truncated, corrupted, or suspiciously short (

  coverage. registerSnapshotIncompleteCount > 0
  ), no baseline is initialized and no deregistration detection runs at all for the affected watches — a partial snapshot never gets silently treated as "nothing changed" or "everyone disappeared." Nothing is billed in that case. Completeness is checked two ways: the downloaded byte count against the response's own Content-Length, and, independently, against the file size/md5 that data.gov.au's CKAN metadata API (package_show) reports for this resource before the download starts — a cleanly-truncated file can otherwise report its own correct Content-Length for a partial body and pass the first check alone.
• This is an informational monitor of a public register, not a real-time charity-status verification service. Always confirm directly with ACNC (acnc.gov.au/charity) before making a business decision.

How it works

1. First run per watch (monitorId + watchId) records a private baseline of every ABN currently matching your state/charitySize filter — no rows, no charge. A baseline is only recorded from a complete weekly snapshot (see above).
2. Every later run re-downloads the register and classifies each ABN in your filter:
   • appeared — a new ABN registration matching your filter appeared;
   • removal_candidate — an ABN you'd seen before is missing from this run's snapshot for the first time in a row. Delivered as an informational row with billed: false — not charged, and not proof of anything (a single missing point is indistinguishable from a transient download hiccup);
   • disappeared — the same ABN is missing for the second consecutive complete weekly snapshot and is also absent from the full register, not just from your filter. Billed: the charity's registration was very likely cancelled.
   • left_filter — the ABN is still present in the full ACNC register this run, but no longer matches this watch's state/charitySize filter (typically the source's own State or Charity_Size field changed). This is not a deregistration signal — the organisation did not leave ACNC, it just left your filter's slice of it. Delivered immediately (no two-strike wait) as an informational row with billed: false — never charged, and never confused with disappeared. If the same ABN later moves back into your filter (e.g. State changes back), that return is symmetric and also free: no row, no charge — it never left the full register, so there is nothing new to report.
3. Only appeared/disappeared are billed, one PPE event each (charity-registration-changed). removal_candidate and left_filter are always informational, never billed.
4. Attribute changes on an ABN that stays registered and stays inside your filter are never reported as an event. This actor is a discovery/membership monitor, not an attribute-change tracker: if a charity's name, town, or other field changes while its ABN keeps matching your filter, no row is produced for that change (the source itself carries no revision history for it either). Only presence/ absence relative to your filter and to the full register is ever reported.

Input

• monitorId — name of this monitor's durable history (a-z0-9-, up to 40 chars). Re-run with the same monitorId to continue the same history; a new value starts a fresh baseline.
• watches — 1-20 objects {"watchId", "state", "charitySize"?}. state is one of NSW/VIC/QLD/WA/SA/ TAS/ACT/NT, or ALL for the whole register with no state filter. charitySize is an optional exact match against the register's own Charity_Size field (Small/Medium/Large) — leave unset to watch every size. Once a watchId is used, its state/charitySize are locked — reusing the id with a different filter fails the run instead of silently mixing histories. Add new watchIds any time under the same monitorId.
• notifyOn / webhookUrl — optional HTTPS webhook receiving a JSON digest of billed changes.

Output

• Dataset — every row this run produced (watchId, abn, status, charityLegalName, stateRaw/stateNorm, postcode, country, charitySize, registrationDate, townCity, eventId, billed). status is one of appeared/disappeared/removal_candidate/left_filter. A durable named dataset holds the append-only history of everything ever delivered under this monitorId; the default (run) dataset mirrors what this run delivered plus a run_summary row.
  • billed on a removal_candidate or left_filter row is always false — never charged, by design.
  • billed on an appeared/disappeared row is written as null. The row is saved to the dataset before its charge is attempted (we never charge before delivery is confirmed — see "Guarantee" below), so the final charge outcome isn't known yet at write time. To find out whether one specific row was actually charged, match its eventId against this run's Pay-Per-Event charged-events ledger in the Apify Console. For the run-level total, use recordsDelivered/recordsBilled in coverage and the unbilled count in digest.
• Key-value store — coverage (per-watch status/reason/matchedCount/candidateCount, requested/ attempted/succeeded/failed, records delivered/billed, total register rows seen and how many had no usable ABN this run; registerSnapshotIncompleteCount > 0 means the weekly download was rejected as incomplete for the affected watches — see "Honest limits") and digest (a short human-readable summary, which also carries this partial-coverage warning even when no billable change occurred).

Guarantee

At-most-once delivery and billing, not exactly-once. A crash right after a right-to-bill is granted can lose that one event (it will not be redelivered), but you will never be charged twice for the same underlying change. See ROADMAP.md for the full claim protocol and its boundaries.

Durable dataset vs. default dataset

The durable named dataset is a journal of delivery attempts across every run of this monitorId — it is not itself proof of payment (a row can in rare crash scenarios be written without a confirmed charge). The default (per-run) dataset mirrors this run's rows plus one run_summary record and is what you see in the Apify Console run view. Reconcile billing against coverage, not row count alone.