Every figure and every mechanism below was read off the running product before it was written down here — the prices out of the live payment catalogue, the counting rule out of the function that does the counting. Where the product does not do a thing, this page says so instead of promising it.
These terms have not been reviewed by a lawyer. They are the product’s own description of itself, published because an organisation deciding whether to trust us deserves a real answer now rather than a page that says “coming soon”.
Version of 14 August 2026. The date at the top is the version — there is no other numbering.
Each one is a fact only the company can state. None of them is guessed here and none is filled in with an example, because a plausible-looking answer in a contract is worse than a visible blank — it is a wrong answer somebody may rely on.
Until these are filled in, nothing on this page should be read as a statement about who the counterparty is or where a dispute would be heard. Everything else on the page is a description of the software, and that part is checkable.
On one side, the company named in the block above — outstanding, and deliberately not guessed at.
On the other, the organisation: the exchange organisation, school, camp operator or agency whose administrator created it in the product. The organisation is identified by the legal name, display name, countries and organisation type recorded when it was created, and by the contact person who created it. Individual people — coordinators, students, host families, teachers — reach the product through that organisation, by redeeming a sign-in code it issued.
One person can hold seats at more than one organisation. Each seat is separate, and moving between them is something a person does deliberately in the role switcher; a seat is never open behind another one.
Audecius Exchange is software for exchange organisations. Its focused Access plan covers administrators, selected staff, student accounts, two-way profile and document exchange, invitations, support, safety and billing. The full-operation plans add the operational areas their plan includes, such as host-family records, placements, school data, messages, incidents, partners and Ariadne.
Access includes the student’s Exchange account in the Web app now and, from Clarity’s early-September 2026 release, in Clarity. It does not include a separate Clarity Premium purchase. It also does not create ordinary seats for local coordinators, host families, parents, schools or partners.
It runs as a console for organisations and a separate surface for students and families. What each person sees is decided by their seat and enforced by the database itself, row by row, under that person’s own sign-in — not by the screen they happen to be looking at.
This document covers the software. It does not make us a party to the exchange programme itself, and nothing here places us between an organisation and the families, schools or authorities it works with.
An organisation issues sign-in codes. A person redeems a code, which creates a membership — the seat — carrying a role. The role decides which views open. The database decides which rows are in them.
Within a record, the organisation controls visibility per field. The record designer’s switches are saved against that organisation, in its own custom-field rows and in its own settings, and they are read back under the token of the person asking — so the switch on the screen is the switch that applies.
The administrator who holds a seat is responsible for who gets a code. We do not vet the individuals an organisation invites.
On Access, administrators can invite other administrators and staff. Only an administrator, or a staff member individually granted the people-import permission, can create or import student accounts. A document uploaded for a student by the organisation is available in that student’s Exchange account; a document uploaded there by the student is available to authorised organisation staff.
Four plans. Each is priced per connected sign-in code, per month, in US dollars.
A “connected code” is a code an organisation generated that has an account connected to it, for a role the selected plan includes. Access counts redeemed administrator, staff and student codes; its subject-bound minor-guardian authority is not a paid seat. Three things follow, and all three are consequences of the same counting rule rather than concessions on top of it:
A code that has been printed, mailed and never redeemed is not charged. A seat that exists without a code is free. And an invitation still waiting to be accepted is not counted until it is accepted.
The count for a month is the number of code-carrying, non-pending seats whose time at the organisation overlaps that month. It is one number, produced by one function, and it is the same number the meter, the pre-invoice and the payment provider all read. An organisation can check it.
The rate is never typed in. It comes from the plan the organisation holds; the database refuses a subscription that carries a hand-entered price, and refuses any currency other than US dollars.
Prices here are exclusive of any tax that applies where the organisation is established. What that tax is depends on the contracting company — see the outstanding block above.
Access includes the same 30-day organisation trial as every current plan. Opening Checkout does not shorten or restart it. No calendar month whose first day falls before the end of that trial is billed. The first billable whole calendar month is invoiced after it closes, using the total connected-code stock that overlapped that month — not merely codes created during it.
Essentials, Placement & Care and Network retain thirty free days. The first-billing boundary derived from the organisation’s stored trial is sent explicitly to the payment provider. Billing starts only after that boundary, and the first charged period is the first whole calendar month after it; the month in which the trial ends remains free.
Nothing is charged during a full-operation plan’s trial, and no charge is made for a period that began before it ended.
Payments run through Stripe. Card details are entered in Stripe’s own checkout and its own customer portal; they do not pass through Audecius and we never hold them.
The same portal is where an organisation sees its invoices, replaces a card, and cancels. Cancelling stops future charges; it does not by itself close the organisation or remove anything — see § 8, which is the honest part of this document.
A cancellation takes effect at the end of the current billing period. The final invoice covers the calendar month that has just ended, using the same connected-code count as every other month; it does not add a proration or charge a future month.
If a payment fails, the subscription moves to a past-due state. Access to a person’s own export is not conditioned on the billing state.
Ariadne is not included in Access. Where a full-operation plan and the organisation’s enabled capabilities include her, she can answer questions about the organisation’s own data and can draft and act inside the console. Three limits are built into how she reads, and they are limits on the software rather than promises about it:
Ariadne chat requires an authenticated user with an active membership in the organisation named by the request. The server applies the organisation’s capability and usage budget; each tool separately enforces its tenant, role, field and connector permissions. Fields withheld by the organisation’s AI field guard, including safeguarding-locked fields, do not enter the prompt through that guarded path.
The model behind her is Anthropic’s, called from our own server function. What leaves, and what it is used for, is set out on the privacy page.
She is an assistant, not a decision-maker. Placement, safeguarding and welfare decisions belong to the people responsible for them.
Any person can export their own data at any time, from inside the product, in one press. The file is assembled from the database with that person’s own permissions and written straight to their disk as JSON — it is not emailed, not queued, and not copied to a bucket somewhere they cannot see. It contains their record, their seats, their placements, the documents on file for them, their consents, the messages sent to them, their devices, the codes they redeemed and their support history.
An organisation administrator can schedule closure in the console. It is a separate server-owned lifecycle; there is no browser permission that can delete the organisation or cascade through its history.
Before the request is accepted, the administrator must download a fresh, uncapped data-table archive containing every offered table and no refused file. It is a portable table export, not a backup of file-storage bytes: the document register is included, while document files themselves must be retrieved separately before access ends.
The server also refuses closure while a student or placement is active, an incident or support request is unresolved, a connected app remains authorised, or the Stripe subscription remains open. Accepted requests expire unused invitation codes and start a 30-day cooling-off period. Existing seats remain available during that period and an administrator can cancel; invitation codes already expired by the request stay expired.
At the due time the server checks every blocker again. If one has returned, closure is held rather than forced through. Otherwise the organisation is marked closed, seats end and connected-app credentials are removed. The operation does not delete people, accounts, programme rows, invitation history or the audit trail; those records remain subject to the retention schedule described on the privacy page.
A person leaving an organisation is a different thing and it does work: ending your own seat is a real action in the product, and it does not touch the account itself.
This document makes no uptime or availability commitment. Saying nothing is more useful than a number nobody measured; if a service level is published it will appear here, with how it is measured.
These terms change by being rewritten and re-dated. The date under the heading at the top of this page is the version in force.
Which law governs this agreement and which courts hear a dispute about it are both outstanding — see the block at the top. They are not guessed at here, and no default should be read into their absence.
Questions about these terms, or help with an organisation closure, go to connect@audeciusofficial.com. The formal contact for data-protection requests is set out on the privacy page.