-cropped.svg)
Your dues report cannot tell you who gets a vote
A payment report tells you what money arrived. It cannot, by itself, tell you who is a member or who may vote. Your association's rules decide that. Before the next general meeting, make one register that connects those rules to actual people and actual orders.
QUICK ANSWER
A payment report tells you what money arrived. It cannot, by itself, tell you who is a member or who may vote. HelloAsso records orders, items and payments separately; an order can even be free. Your association's rules determine membership and voting rights. Before the next general meeting, make one register that connects those rules to actual people and actual orders. If that register needs a spreadsheet detective every year, the system needs fixing.
Picture the secretary of a French association the week before its general meeting. The treasurer exports payments. The membership lead exports signups. Both files look complete. One person paid for two places. Another registered through a free category. A third paid in instalments. Which names belong on the voting list?
The answer is not in either export alone. That is not a flaw in HelloAsso. It is a mismatch between what a payment system records and what an association needs to decide.
A payment proves money moved, not membership
HelloAsso's API documentation distinguishes an order, the items inside it, and the payments attached to it. An order may be free or paid in several instalments. One payment can cover several items. A campaign may sell event tickets, collect donations or take memberships.
So a row in a payments export proves a transaction was recorded. It does not say whether the item was a membership, who the membership belongs to, whether it is current, or whether that person has a vote. The same person may appear in several orders, while one order may contain several people or purposes.
Figure 1Membership evidence
Money received is not a voting list.
Each system answers a different question. The association must write the rule that connects them.
Your statutes decide who belongs and who votes
The association does. France's official association portal says dues are not systematic. They may apply to all members or only some categories, and the association's rules set their amount and payment period. Its guide to drafting statutes says statutes can set admission, removal, governance and members' powers.
That makes a clean sequence: read the statutes and any internal rules, identify the membership categories and their conditions, then decide which evidence in the platform proves each condition. Payment may be one condition. It is not a universal definition of membership. Voting rights need their own rule.
This is the distinction that matters before an assembly. A payment export is an accounting view. A voting list is a governance decision. Treating them as the same file can make the count look tidy while the underlying decision remains unexamined.
Free orders and instalments break a payment-only list
It can fail at the point where a person, a membership item and a payment are joined. A free membership can be absent from a payments export. An instalment plan can create several payment records for one order. An event ticket or donation can be mistaken for dues if the report is filtered by money rather than item type. Someone who paid can still be in a category without a vote under the association's rules.
These are possible failure modes, not a claim that HelloAsso has misclassified anyone or that your association's register is wrong. You can test your own process with a handful of real orders before drawing that conclusion.
A thank you page cannot verify an order
No. For a checkout integration, HelloAsso warns against treating the browser's return URL as payment validation. The visitor can close the page, lose the connection or alter the returned code. HelloAsso recommends server notifications or a check against the checkout intent, and sends separate order and payment notifications.
That technical point has a human consequence. If a website grants member access as soon as the browser lands on a thank you page, the website can make a membership decision before it has verified the order and payment. The correct entitlement still depends on the association's rules, but the system should at least know what actually happened.
The register must show why each person qualifies
One person record, the membership category, the relevant order item, the dates that make it current, the payment state if payment matters, and a clear reason for any voting entitlement. A human should be able to correct an exception without editing several disconnected lists. The treasurer should still have a payment report, because money and membership answer different questions.
That reason should be legible to the board. “Active because the annual membership item belongs to this person and the current statutes give this category a vote” is a useful explanation. “Active because a row matched on email” is only a technical guess. People change email addresses, and a payer can pay on someone else's behalf. The membership record needs a stable person identity and a way for the secretary to resolve ambiguity.
The integration should flag exceptions instead of guessing
An integration can join a person to an order, classify a membership item, check its dates and attach the payment state. It should also leave a visible queue for cases the rules cannot decide automatically: a name that appears twice, an order for another person, a manual admission, a refund, or a membership category the system has never seen before. Silently assigning a vote is the wrong way to make the dashboard look clean.
The secretary should be able to inspect the evidence, record the decision and see who made it. That gives the next board a repeatable process instead of an undocumented exception in one person's spreadsheet. The exact categories and entitlements must come from the association's own rules; a software vendor should not invent them.
Start for free. Take your statutes, the latest membership export and the payment export. Pick several edge cases: a free member, a person paying in instalments, an order with more than one item, a lapsed member and a donation without membership. If you can explain each person's membership and vote from those records, the process may be sound. Write that rule down so the next secretary can repeat it.
A spreadsheet fails when the rule lives in one volunteer's head
When the answer depends on one volunteer remembering which columns to merge, which duplicate to ignore and which exception to override. That is a fragile assembly process, even if the final spreadsheet is correct. The volunteer who did the reconciliation becomes the undocumented system.
Elevates can map the association's membership rules to the actual HelloAsso order and item data, verify checkout events where there is a custom integration, and build a register with explicit exceptions and a handover path. The deliverable is not another dashboard of payments. It is a membership view the board can explain and the next board can operate.
If your payment report and voting list already reconcile cleanly, keep them. If nobody can show the rule connecting them, work with Elevates to make that rule visible before your next assembly.