CLE Registration & Credit Reporting

The vertical decides the vocabulary, the questions asked at checkout, the inventory model, the door, the payout terms and the theme. This page says "seat" and "course" because that is what a provider says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

The only proof that anybody sat the session is a clipboard by the door

A sign-in sheet is signed by the people who arrive early, passed down a row by the people who do not, and photographed at the end of the day in bad light. It records that somebody wrote a name at some point in a room — not which sessions they sat, not when they left, and not legibly enough to reconcile against a registration list a year later. The exposure is asymmetric, too: the attorney claiming the hours is not the one who has to produce the evidence. The accredited provider is, and by the time anyone asks, the person who ran that Thursday has left and the sheet is in a box.

What bindro does: Each session is scanned on its own. A credential is scoped to the sessions it was sold for, so an attorney admitted to the morning is simply unknown at the afternoon door, and each scan is written against that session rather than against the day. What you hold afterwards is not a sheet somebody has to interpret but a per-session attendance record with a time on it, which is the record credits are then derived from. Nobody reconciles anything afterwards, because the reconciliation is the door.

Certificates are a week of somebody's evenings, and then they are re-sent all year

The mail merge is the visible cost: a spreadsheet of names against hours, a template, a serial column somebody increments by hand, and an afternoon of sending. The invisible cost is the next eleven months, because a certificate is the one document an attorney loses and needs urgently, usually a fortnight before a compliance deadline. Every re-send is a person opening the spreadsheet again and deciding whether to reuse the old serial or mint a new one — and a second serial for the same hours is precisely the thing that makes a record look manipulated when it is only untidy.

What bindro does: Issuing is one action per session, taken after that session has ended. Bindro writes one credit per verified attendee carrying the session's contact hours — computed from its own start and end times, not typed — and a unique serial, and each certificate is a page addressed by that serial so it can be verified by quoting the serial alone. Issuing again for the same session is idempotent: it fills in anyone who was missed and never mints a second credit for someone who already has one. A session that has not ended yet is refused outright rather than issued early.

The firm's accounts payable department does not have a credit card

A partner wants six of their associates on Tuesday's seminar and forwards you to a purchase order, terms of thirty days and an AP portal. The registration platform wants a card number. So the seats get held on trust in a spreadsheet, the invoice goes out of an accounting package that knows nothing about the course, and the reconciliation between the two lives in one person's memory. The failure is not usually a firm that refuses to pay; it is a course that ran with six seats nobody ever billed for, discovered in a quarter-end that is already busy.

What bindro does: The checkout offers to invoice the organisation, and an invoiced registration confirms with no card at all. Bindro issues a numbered bill carrying the firm's own PO number and your standard terms, commits the seats immediately, sends the bill to accounts payable and the credentials to whoever booked. The accounting is the careful part: issuing an invoice writes no ledger entry whatsoever, so your balance cannot carry a registration nobody has paid for and a payout can never be funded by an outstanding bill. Someone with finance rights records the settlement when the remittance lands, recording it twice is refused, and an invoice that passes its due date unpaid is voided automatically with the seats returned to sale.

The member rate is a discount code, and the code is on a listserv by Wednesday

For a bar association the member price is not a promotion, it is the membership benefit — the reason a subscription gets renewed. Running it as a code hands that benefit to whoever forwards the email, and the leak is invisible until somebody totals the year and finds the non-member rate was theoretical. The other half is worse for goodwill: a member whose subscription lapsed in March is charged the member price by a code that does not know, and the conversation about the difference happens after they have already sat the course.

What bindro does: The member rate is a property of the seat type, and the membership reference an attorney types is checked against your own roster inside the transaction that takes the money. A current member is charged the member rate; a lapsed or revoked reference is refused with a message against that field rather than quietly charged full price; and the order line records why the seat was cheaper, so the year-end split of member against non-member revenue is a query rather than an archaeology exercise. Only a one-way digest of the reference is stored — the console can show a name and whether the membership is current, and can never read the number back, because a number that unlocks a price is a bearer secret.

A firm books eight seats and names nobody until the morning of the course

Block bookings are how a lot of CLE actually sells, and the names always arrive late: a forwarded email at nine the night before with seven names and a "plus one more to confirm". Registration lists get edited by hand at breakfast, the door list is out of date before it is printed, and somebody walks in claiming a seat that is recorded under a partner who is not in the building. That last one is the expensive version, because the credit for the session then attaches to the wrong admitted attorney and the certificate carries the wrong bar number.

What bindro does: A firm pays for the places up front and gets a roster it fills in afterwards, either by typing the names or by emailing each place to the attorney taking it so they complete their own details. Filling the roster never creates inventory — it renames seats the order already paid for — so a firm cannot quietly grow its block past what it bought. A place nobody has named stays off the door list and is refused if it is scanned, which is the rule that stops an unnamed seat becoming an unattributable credit. Worth being plain about the money: a block is priced from the seat rates you published, because bindro has no separate group price a provider can set.

The conference wifi is a promise made by somebody who is not standing at the door

Registration for a full-day seminar happens in about twelve minutes, in a corridor, with ninety attorneys who all have a call at nine. That is the moment a hotel's guest network decides it wants a room number, or the ballroom turns out to sit under the one dead spot on the floor. What happens next is always the same: the tablet goes away and a printed list comes out, and the per-session attendance record — the entire reason the scanning existed — becomes ticks in biro that somebody types up on Monday.

What bindro does: The door expects no signal, because that is the actual situation rather than a degraded version of it. Each device syncs a signed manifest of who is expected at that session, validates scans locally with no network at all, and uploads its shift log when it can; re-uploading counts as a duplicate rather than a second admission. Where a code cannot be produced, a name can be found on the same screen. Run several doors and a clash — the same attorney scanned in two places — lands in a conflict queue for a human to look at instead of the system silently picking a winner. Two honest limits: an offline count is only as fresh as its last sync, and remaining capacity goes live again when the device is back on the network.

Credit derived from the door, never from the sale

This is the capability the vertical is built around. Attendance is captured per session at the door; credits are issued from those records afterwards, one per verified attendee, carrying that session's contact hours and a unique serial. The chain from a scan to a certificate is short enough to explain to an auditor in one sentence, which is the property that matters here.

• Contact hours come from the session's own start and end times, so the certificate cannot disagree with the programme.
• One credit per attorney per session, with a serial that verifies the certificate on its own.
• Re-issuing a session is idempotent — it never mints a second credit for an attorney who already has one.
• A session that has not ended is refused: there is no way to issue credit for a room that has not happened yet.
• A comped seat earns credit identically, because the credit follows the scan and not the money.
• A registrant who never scanned in gets nothing, and that is the point rather than a gap.

Member and non-member rates your own roster decides

Member pricing is enforced on the money path rather than suggested in a description. You publish a member rate and a non-member rate on the seat type, and the membership reference is verified against your roster inside the confirming transaction — the browser never states a price, and no code has to be kept secret. Seat tiers sit alongside it, so an early rate and a walk-up rate can run on the same course.

• A lapsed or revoked membership is refused against the field, before the money moves, rather than argued about afterwards.
• Only a digest of the reference is stored: the console shows a name and a status, never the number.
• The order line records why a seat was cheaper, so the member versus non-member split is a report rather than a reconstruction.
• Promo codes exist for the cases pricing does not cover — a speaker's firm, a reciprocal arrangement with another bar.
• Subscription and season-pass pricing are deliberately not offered here; the payout section explains why, and it is structural.

Purchase orders that stay out of your balance until the money arrives

Firms buy CLE the way firms buy everything: a purchase order, terms, and an accounts payable department that will not be hurried. Bindro treats an invoice as what it is — a promise rather than money — and the accounting follows from that single decision, which is why an unpaid bill can never inflate a payout.

• The checkout offers to invoice the organisation; the registration confirms with no card and the seats are committed.
• The bill is numbered, carries the firm's PO reference and your terms, and goes to accounts payable while credentials go to the booker.
• Issuing writes no ledger entry at all; the sale is written when a settlement is recorded, and recording it twice is refused.
• Recording a settlement is a finance-rights action, not something a door login or a programme coordinator can do.
• An invoice past its due date is voided automatically and the seats go back on sale rather than sitting held indefinitely.

Firm bookings with a roster the firm fills in itself

A block booking is one order for several places and a roster that gets completed later — by you, or by the firm, or by the attorneys themselves when each place is emailed to the person taking it. The seats are paid for at the point of booking; the names are the part that arrives late, and the system is built to expect that rather than to be surprised by it.

• Filling a roster renames seats the order already bought — it never creates inventory, so a block cannot grow past what was paid for.
• An unnamed place is kept off the door list and refused at the scanner, so it cannot become a credit with nobody's name on it.
• Each named attorney gets their own credential, their own scan record and their own certificate.
• Registration answers — bar number, employer — are collected per attorney, not once for the whole firm.
• A block is priced from the published seat rates, including the member rate where the attorney qualifies; there is no separate group price to set.

A door built for a ballroom with no signal

Offline is a requirement in this vertical rather than a feature, so it is designed into the data model instead of retrofitted onto a web page. The device holds a signed manifest for the session in front of it, admits people with no network at all, and reconciles when it gets one. Several doors can run at once for a multi-day institute, each one scanning its own session.

• A credential presented at the wrong session reads as unknown rather than being admitted — the behaviour that makes per-session credit trustworthy.
• An attendee returning through the door that admitted them is readmitted as a re-entry; the same credential at a different door reads as already used, which is what a phone handed over looks like. The attendance is counted once either way.
• Clashes across doors queue for review instead of resolving themselves silently.
• Live remaining capacity, per session, on the day-of screen while the device is online.
• A door login sees a name and whether the credential admits — not what anyone paid, and not what anyone else answered.
• Walk-ups and phone registrations go through the back office onto the same door list, the same pool and the same credit run.

The registration form a CLE provider would have built anyway

The form arrives already asking for the bar number and the employer, with the membership reference, dietary and accessibility questions beside them, because those are the fields this vertical needs. Questions can depend on earlier answers, and the rule is enforced where the money is rather than in the browser — which matters when half your registrants are on a locked-down firm laptop with scripting restricted.

• A question hidden by a rule is not required; a question the rule reveals is; a hand-posted answer to an invisible field is refused.
• Unknown answer keys are rejected at validation rather than stored, so nothing lands in an unaudited column.
• Sensitive answers are classified on the field itself, which drives redaction, retention and their absolute exclusion from analytics exports and AI context.
• Attorneys refund themselves from a signed link in their confirmation until the session starts; after that it is the provider's call from the console.
• A post-course email goes out on its own, and the attendee list exports as CSV whenever you want it.

Who pays the booking fee?

The attorney, unless you say otherwise. Every course carries its own setting — the attorney pays, you absorb it, or you split it — and the fee itself does not change with the choice, only which side of the sale it comes from. On a ten-seat $25.00 course that is $16.20 either added to what attorneys pay or taken out of what you keep.

Because the default is the attorney, a provider can go from signing up to a sold-out course without paying bindro anything up front, at any point, ever. We are paid out of sales that happened or we are not paid.

The word "event" is load-bearing and worth reading twice. The scheduler groups by course, admits one only once its LAST session has ended, and pays it once. A course sold as a run of dates therefore pays after the final date, not after each one — a season's float is not something an operator should discover halfway through the season.

Bindro never pays before delivery, in any vertical. A pre-event advance is a configuration violation platform-wide rather than a policy someone can be talked out of, because paying out on courses that have not happened is exactly how a cancellation becomes attorneys with no refund. "Paid" also means the money moved: a payout only reaches its paid state with a real transfer reference attached, enforced by the database rather than by a status field someone can set.

• One payout per course, after its last session ends, one in flight at a time.
• T+2 for this vertical (low risk tier), no reserve.
• Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refund never leaves you charged for a sale that was undone.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance, so the payout figure is proceeds rather than a number you still have to do subtraction on.

The console shows the two halves of that figure on one page. Every ended session is listed with its contact hours, the count of verified attendees and how many credits have been issued against it, so a session that was scanned but never issued is visible rather than forgotten — and the issued certificates are listed underneath with their serials, hours and dates, each one linking to the certificate itself. Multiply and add and you have the year; the page is a working list rather than an annual return, so the totalling is a spreadsheet away through the export.

The three numbers this vertical is scored on beside it are jurisdiction mix, member versus non-member mix and filing latency, and they deserve different degrees of honesty. The member split is real and comes off the order lines, because the price that was applied is recorded with the reason. Jurisdiction is not collected by default — the form asks for a bar number, not a state — so if you want the mix you add jurisdiction as a registration question and it comes back in the export with everything else. Filing latency measures a step bindro does not perform at all: the clock we can honestly stop is the one from a session ending to its certificates being issued, and what happens after that is between you and the bar.

Everything else the console reports is what you would expect and nothing you would not: gross, platform fees and refunds per course read from the same ledger the payouts reconcile against; seats sold against attorneys checked in with a no-show percentage per session; live remaining capacity while registration is open. The headline figure is computed and the arithmetic is printed under it, which is where the honesty lives: credit hours delivered is attendee-shaped until the credit module records its own units, so the number counts attorneys on delivered courses and the basis line says exactly that.

What the console shows today, without an integration or a spreadsheet:

• Gross, platform fees and refunds per course, read from the ledger the payouts reconcile against.
• Seats sold against attorneys checked in, with a no-show percentage per session.
• Live remaining capacity while the course is running, per pool, on the day-of screen.
• This provider's own funnel — view → session selection → checkout → paid → attended → credit filed — stage by stage with the drop-off between them, and any step the platform cannot see said so rather than shown as a zero.
• Refunds, transfers, turnout, no-shows, add-on attach and repeat buyers, each printed with the two numbers it was divided from.
• Orders and attorneys as CSV, so anything not on the screen is one export away.

Two more that are worth stating plainly. Sensitive answers are classified on the field rather than by convention, and health data is excluded from analytics exports and from AI context absolutely, with no override in any vertical. And a provider's own people see only what their role allows — a door login sees a name and whether the code admits, not what anyone paid — which is checked in the handler rather than by hiding a button.

• Filing credits with a state bar — nothing in the engine transmits anything to any jurisdiction. Bindro issues the per-session hours and the certificates; the provider files them, exactly as they do today.
• Credit categories — a credit record carries hours, a serial and the session it came from. Ethics, technology and specialty-credit categories are not modelled, so the split has to come from how you structure the sessions themselves.
• Collecting a bar card or admission certificate at registration — document upload is optional for CLE providers and is not turned on, so the file control does not render.
• Board and quarterly activity reports — configured as optional for this vertical and not resolved; the console page is a hard refusal rather than an empty report.
• Webcast, on-demand and recorded CLE — bindro sells the seat and admits at the door. It hosts no content and has no learner record, and a credit here comes from a scan.
• Picking sessions across a multi-day institute in the hosted checkout — the hosted flow sells one session per order today; multi-session orders ship on the public JSON API.
• Annual all-access CLE subscriptions — payouts settle per delivered course, so subscription revenue could be taken and never paid out. It is refused on purpose.
• Paying for a seat in instalments, or deferring a seat to a later run of the course — both are optional for this vertical and are not enabled.
• Printed name badges — badge printing is optional here and not resolved; check-in is by QR.
• Handing a seat to a colleague — ticket transfer is not declared for CLE providers, so a direct call is refused rather than quietly reassigning the credit.
• Waitlists on a fully subscribed course — a waiting list is not enabled, so full is full.

If one of those is the thing you need, say so — the answer is a capability declared, built and gated properly, or a straight no. It is never a feature flag that collects the request and does nothing.

Setting up is the short part. A course carries its sessions, and each session carries its own capacity and its own door — which is worth thinking about before you publish, because sessions are also the boundary credit is issued on. A half-day with a break is one session if the hours are one block, and two if they are two credits; structuring on the credit boundary rather than on the room timetable saves a conversation with an auditor later. Seat rates go on next: a member rate, a non-member rate, and tiers if an early rate is part of how you sell.

Selling happens on your own course page, or through the checkout embedded in the site you already have — a bar association usually has one, and sending members off it to a platform-branded page is a conversion cost with no upside. Firms take the invoice route, individual attorneys pay by card, and anybody who telephones gets registered from the back office onto exactly the same seat pool. Nothing is a separate ledger or a spreadsheet row.

On the day the tooling is one-handed and standing up. Scan the session, admit the walk-ups you take, watch capacity where you have signal, and do not think about the network where you do not. Afterwards, issuing credit for a session is one action and can be repeated safely, the post-course email goes out on its own, and the payout arrives two days after the last session ends — one payout for the course, never before it has been delivered.

• Structure sessions on credit boundaries; capacity, doors and certificates all follow the session.
• Publish a member and a non-member rate rather than a code somebody can forward.
• Point firms at the invoice route; it commits the seats without touching your balance.
• Scan every session, including the last one people are tempted to leave early from.
• Issue credit once each session has ended; re-run it safely for anyone who was missed.

This is the first question every CLE buyer asks, so it is answered on the landing page rather than three clicks into a support article. Reporting duties genuinely differ by jurisdiction: some bars expect the accredited provider to report attendance, others expect the attorney to self-report against a certificate, and the deadlines, formats and transmission methods are not the same in any two places. Bindro takes no position on which apply to you, because a confident wrong answer about somebody's licence is a professional liability event rather than a support ticket.

Some established CLE platforms do offer state reporting as part of what they sell. If filing on your behalf is the requirement, that is a real reason to choose one of them, and the comparison pages linked from this page say so plainly rather than burying it — check their current documentation rather than taking our summary of what a competitor does. Bindro is the layer underneath: registration, money, the door, and the credit record itself.

The related limit belongs in the same breath, because it disappoints people at the same moment. Credit categories are not modelled: a credit record carries hours, a serial and the session it came from, so an ethics or specialty split has to come from how you structure the sessions rather than from a category field. The board and quarterly activity reports some providers want are configured as optional for this vertical and are not turned on, which means the console page is a hard refusal rather than an empty report — a gap you can see rather than one that looks like a bug.

The useful property is that none of it was assembled for the audit. The attendance record is the door doing its job, the certificate serial is the artefact the attorney already has in their inbox, and the price applied to a seat is on the order line because that is how the money worked. A record built at the time by the system that ran the course is worth more than a reconstruction, and it is considerably faster to produce.

Verification runs both ways. An attorney can be checked against a serial, and a session can be checked against the list of everybody who was scanned into it. Because credit comes from attendance rather than from the sale, the two most awkward audit cases answer themselves: somebody who paid and did not come has no certificate, and somebody who came for the morning has the morning hours and nothing more.

Access to all of it is governed by role rather than by who knows the URL. A door login sees a name and whether a credential admits; recording a settlement against an invoice needs finance rights; reading the credits page needs reporting rights. That is checked in the handler rather than by hiding a button, which is the difference between a permission and a layout. And everything exports — orders and attendees as CSV, whenever you want them, with no export fee and no notice period, because a record you cannot take with you is not really yours.

The multi-session limit is the one most likely to affect a real programme, so it is worth being exact. Multi-session orders exist — one order, one line per session, a credential per attorney per session that admits at that session only — but they ship on the public JSON API today, while the hosted checkout page still sells one session per order. An institute run through the hosted flow therefore sells each session as its own registration, which works and is more clicks than it should be. A guide linked from this page walks through what that looks like in practice.

The subscription refusal is structural rather than a missing screen, and the mechanism is worth understanding because it explains why no amount of asking will change it. Payouts settle per delivered course: the scheduler groups by course, admits one only once its last session has ended, and pays it once. Money taken for a year of unspecified future courses has no delivery event to release it against, so it would sit in a balance the payout engine could never pay out. Taking money we could not pay you would be worse than refusing it, so the checkout refuses it.

On the rest, the honest framing is that these are configuration decisions for this vertical, not permanent verdicts. Document upload would let you collect a bar card image; deferral would let an attorney move to a later run; badge printing is a conference-desk convenience. Each is off, and each is refused at the call with a hard error rather than quietly doing nothing — which is the failure mode that actually hurts, because it looks like it worked. If one of them is the thing you need, say so: the answer is a capability declared, built and gated properly, or a straight no.