How to collect payments and issue invoices

The conference fee is usually the first reason an organizer stops collecting registrations in a spreadsheet. Payments have to be taken, matched to registrations, documented, and you need to know who still has not paid. In the SF-CONFERENCE system all of that happens against the attendee’s registration: the amount follows from what they chose in the form, and the documents are issued from their details.

Below we go through the configuration in order: currencies and tax, bank transfer, online payments, and then invoices, the numbering, the templates and automatic issuing.

Currencies, tax, and net or gross prices

It all starts under settings in the panel’s side menu, in the payments tab. The currencies field decides what the attendee pays in; there may be several, and then every price in the form is given separately in each of them. There is no automatic conversion here and that is deliberate. The price for an overseas attendee is rarely a straight exchange-rate calculation.

Next you set the VAT rate or, where exempt, the reason for the VAT exemption. Separately you decide whether the prices entered on form fields are net or gross: the gross prices toggle changes the meaning of every amount in the system, and show only gross hides the split into net and tax from the attendee. It is worth setting this at the start, before you enter any prices. Changing it later means recalculating every option.

Bank transfer

The simplest method needs no integration at all. In the payment information section you fill in the transfer details: the recipient, the account number, the bank’s name and address, and the SWIFT code. Those details reach the participation summary page and the registration confirmation message, and in the transfer title the system suggests a payment identifier, which is what lets an incoming payment be matched to a registration later.

Payments arriving by transfer are marked under payments. Until they are marked, the registration counts as unpaid, which is visible both in the panel and on the attendee’s side.

Online payments

In the same tab you will find the online payment operator section. For events settled outside Poland that operator is Stripe: an Available toggle and below it fields for the publishable key, the secret key and the webhook secret, all copied from your Stripe dashboard.

Once the details are in, use the test connection button at the top of the tab. It checks the configuration before the first attendee tries to pay, and that is a far better moment to catch a typo in a key than a message from someone whose payment failed.

If you want the attendee to pay straight after submitting, switch on payment in form on the registration form’s page. With two or more methods enabled the attendee picks how to pay while still in the form, and after submitting lands directly on the payment page. The building the registration form guide covers this in more depth.

Invoice numbering

Invoices are a module of their own. You turn it on in the modules tab and configure it in settings, in the invoices section. Start with the invoice numbering, because without one no template can be created.

You build the numbering from parameters: the year, month and day of issue, plus the consecutive number within the day, the month, the year or since the event began. Separately you set how many digits each of them uses. That way you reproduce the numbering your accounting already uses, instead of bending it to fit the system.

Invoice templates and automatic issuing

An invoice template describes one kind of document. The choices include a proforma, a VAT invoice, prepayment and settlement invoices, and correcting documents. On the template page you set the due date, the tax rates, how the issue date and delivery date are calculated, and the content of the document itself.

The two toggles deciding when the document is created matter most, though. After payment is created issues it at the moment the registration is accepted. That is how a proforma usually works, since it is the basis for paying. After payment is paid waits for the money and only then issues the document. That is how a VAT invoice usually works.

On top of that come the issuing conditions, the answers from the form at which the document should be created at all. The commonest use is the "I want to receive an invoice" question: the VAT invoice template then applies only to the people who ticked it. A freshly created event has automatic issuing switched off, so until you turn it on no document is produced.

For an invoice to carry the buyer’s details, the form fields have to be marked with the right properties, the company name, tax number, address, postcode, city and country each have their own property prefixed with invoice. The system then knows which answers to copy onto the document.

You can see the result under Invoices in the side menu. Every document there has its number, the template it came from, an amount and a status, and from the list you can download it as a PDF or resend it to the attendee.

Where the attendee finds their documents

Issued documents reach the participation summary page, the same one where the attendee sees their registration details and payment status. So they need not write asking for an invoice or wait for someone to dig it out of a mailbox. In the panel all the documents live under invoices, with a preview and a file download.

Currencies, issuing conditions and later payments

A payment gateway is not required for any of this: a bank transfer works with no integration at all. You only fill in the transfer details and mark payments by hand under Payments. You can also sell in several currencies at once; you set them in the Payments tab, and then give every price separately in each of them. Rates are never converted automatically, so the amounts are exactly what you typed.

An invoice need not be produced for everyone. A template carries issuing conditions based on answers from the form, so the document is created only for a given answer, after ticking a “I want to receive an invoice” field, for example. If an attendee buys something after registering, a separate payment appears, independent of the registration fee, that is how workshop sign-ups run through a custom form behave, and documents are issued against it from the same templates.

Payments in short

The order is always the same: currencies and tax first, then the payment methods, and finally the numbering and invoice templates with their issuing conditions. The amounts come from the prices set on the form fields, and the buyer’s details from the fields marked with the invoice properties, which is why it is worth having a finished registration form before you start configuring invoices.