Matching bank payments with an OCR file

OCR is an agreement between the organiser and the bank, not something Profixio can switch on by itself. In Norway this is the OCR-giro agreement your bank offers; the bank then delivers the payment files that Profixio collects.

Three things in the bank agreement must line up, and the bank has to get them right:

1. The account number in the bank agreement must be exactly the account number registered on the OCR agreement in Profixio. Payments credited to any other account are read but not matched.
2. The number of digits in the KID must be the same in the bank agreement as in Profixio. If they disagree, the KID printed on your invoices is not the KID the bank expects, and payments come back unusable.
3. Profixio must be listed as the recipient of the transaction data in the agreement, with the customer id Profixio uses to collect the files. Ask support for the exact id to give your bank. Without this, the bank produces files that never reach Profixio.

Both you and the bank can see the agreement, so both sides can check these three points. The Profixio side of the same three values is on the OCR agreement page described below.

Once the bank agreement exists, contact support: the OCR module has to be enabled for your tournament before the OCR menu entries appear at all. The invoice settings page says so directly - the OCR switch there is greyed out with the note "Contact Support for help setting up automatic OCR invoicing".

Open Economy in the tournament admin menu and choose OCR avtale. The page is titled Oversikt over OCR-avtaler and lists the agreements belonging to your organisation's Profixio account, with a tick in Active for this tournament on the one this tournament uses.

An agreement holds:

• Banknavn - the bank's name, also printed on invoices.
• Kontonr - the account that receives the payments. The helper text spells out which account this is: "Kontonummer som godskrives for summen av innbetalinger (oppdragskonto)."
• Bankiban and Bankswift - used on invoices, and used instead of the account number for the EU file format.
• Kid antall siffer - how many digits the KID has, including the one check digit. Between 3 and 25; the helper text recommends keeping it as short as possible.
• Kid teller - the number the KID series starts counting from. On a new agreement it must have fewer digits than the KID length, otherwise saving fails with "The start counter is to long. It must be 1 less than the "kid antall siffer"".
• OCR format - which bank file format the agreement produces: Nets (Norway), BgMax or EU ISO 20022 (RF-0810016).
• Linked tournaments - a tick list of the tournaments the agreement applies to.

The linking rule matters more than it looks: "En avtale kan knyttes til en eller flere av turneringene. Da vil KID-nummer genereres i samme serie på alle valgte turneringer. En turnering kan knyttes til maksimum en OCR-avtale." One agreement can serve several of your tournaments, and they then share one running KID series, so no two invoices anywhere in that account get the same KID. A tournament can only use one agreement.

Unticking a tournament removes its link to the agreement, which means new invoices for that tournament stop getting KID numbers. An agreement that is still linked to at least one tournament cannot be deleted.

The Kid antall siffer, bank name, IBAN and SWIFT values also appear under OCR Information in the tournament's Invoice Settings, and editing them there edits the same agreement - including for every other tournament linked to it.

A KID is generated the moment an invoice document is produced, not when the team registers. Each invoice gets its own KID, with the number of digits set on the OCR agreement, and Profixio makes sure the KID is not already in use anywhere in the organisation's account.

What this means in practice:

• The KID identifies one invoice, nothing else.
• A team that pays with the wrong KID pays somebody else's invoice. The payment lands on whichever invoice owns that KID, and both teams then look wrong in the ledger. This is the single most common cause of "we have paid but Profixio says unpaid".
• A team that pays without a KID cannot be matched at all. The payment shows up in the import with an empty or unknown reference and has to be registered by hand.
• Reminders and credit notes follow the same invoice, so the KID a club is holding on an old invoice keeps working unless the invoice itself was credited and reissued.

Tournaments without a bank agreement do not get KID numbers; their invoices carry a text payment reference you compose yourself. Setting that up is covered under Invoicing teams.

There are two routes, and which one applies depends on the file format on your agreement.

Automatic collection (Norwegian files). For agreements using the Norwegian bank format, Profixio collects the files itself. Nobody has to do anything: new payments simply appear in the OCR import list, usually within the hour after the bank releases the file.

One file can contain payments for several tournaments and several accounts at once. Profixio splits it up: for every payment it looks up the invoice with that KID and checks that the account credited in the file is the account on that tournament's agreement. Each tournament that has payments in the file gets its own import row.

Manual upload (other formats). For the Swedish and EU formats there is no automatic collection. Someone has to download the file from the bank and upload it on the OCR import page.

If you use the Norwegian format and no new imports have appeared for days, that is a signal in itself - see the checklist at the end of this page.

Open Economy in the tournament admin menu and choose OCR kjøring. The page is titled OCR historikk.

1. Click Last inn OCR-fil at the top of the list.
2. Pick the file you downloaded from the bank under Select an OCR file.
3. Save. The file is read straight away and the result is shown as a message on screen - the same status text that then appears on the new row in the list.

Things that stop the import before it starts:

• "No OCR agreement is configured for this tournament" - the tournament is not linked to an agreement. Link it on the OCR avtale page first.
• "Empty file" - the file contained no content.
• The file is rejected if it is larger than the upload limit for the site.

Uploading the same file twice is harmless: the second import records the bank's batch number, sees that batch has already been processed, and stops without creating anything. It appears in the list with a warning status rather than doubling anyone's payments.

The file itself is kept with the import. Vis fil on any row downloads exactly what was read, which is what support will ask for if the numbers look wrong.

Each row in OCR historikk is one file that was read for this tournament, newest first.

A healthy import has the two counts equal or close, OK ticked, and the status OCR Payments updated. A gap between the two counts means some lines did not find an invoice; open the import to see which.

Opening an import shows the same figures plus Betalinger tilbakestilt and, when something went wrong, the raw Feilmelding from the file check.

Note what OK does not mean: it is ticked as soon as one payment was registered, even if ten others in the same file were left unmatched. Always compare the two counts.

Open an import and the OCR-betalinger table below shows one row per payment line in the file - every payment, matched or not.

Some of these columns are hidden until you switch them on with the column chooser.

List of OCR payments, at the top of the OCR pages next to OCR historikk, shows the payment lines from all the imports in OCR historikk in one list, with search and filters. Opening a row there, or inside an import, shows that payment line's full details.

A row with both ticks is finished business. A row with neither tick is an unmatched payment, and the section below explains what to do with it. A row with Faktura ticked but Betalt empty is rare and worth reporting to support.

The amount registered is whatever the bank line says. A team that paid too little or too much still gets a payment registered - the difference then shows up as an outstanding or negative balance in the team ledger, which is where you deal with it.

An unmatched line means the money is in the bank but not on any team. There are four usual reasons.

The payer used a wrong or missing reference. By far the most common. The KID belongs to nobody, or worse, belongs to another team's invoice. Find the payer from the amount and the paying account, then register the payment manually on the right team from the team ledger, and treat the KID confusion as its own problem if the money landed on someone else's invoice.

The invoice had not been made yet when the payment arrived. A club paying from an old invoice or a pro forma amount pays a KID that does not exist yet. Create the invoice, then register the payment manually on the team from the team ledger.

The payment went to a different account. A payment only matches when the account credited in the file is the account number on the agreement. If the organiser moved bank accounts and the agreement still names the old one, every payment in the file is read but nothing is registered.

Two invoices share the same KID. Then Profixio refuses to guess. The import registers nothing for that payment line; contact support to sort out the shared KID.

Payment lines in an import are read-only: whatever the cause, an unmatched payment is registered manually on the right team from the team ledger.

A matched payment is an ordinary completed payment on the team. It appears immediately:

• in the team ledger, reducing what the team owes,
• on the team's Economy tab together with any manually registered payments,
• in Economy - List payments, where it is shown as registered by OCR import,
• and on the invoice it paid.

The payment is dated the bank's settlement date, not the day the file was imported, so an import that arrives on Monday can produce payments dated Friday. It is booked against the same thing the invoice covered - the registration fee or the ordered services - so a team with separate invoices for fee and services gets separate payments.

If the club wants confirmation, they see it themselves on their team page.

Matching is deliberately one-way on these screens. There is no button to undo an import or to unlink a payment, because undoing the wrong import used to remove payments from a completely different tournament.

So if a payment landed on the wrong team - normally because the payer used another team's KID - fix it in the ledger rather than in the import:

1. Register a correcting payment with a negative amount on the team that was wrongly credited, from that team's Economy tab.
2. Register the payment on the team that actually paid, for the same amount.
3. Tell the club which KID to use next time.

Both steps are done from the team ledger and are described under The team ledger and chasing payments. The import row itself stays as it is - it is a record of what the bank sent, and it should not be rewritten.

If an entire import went wrong - for instance the wrong file was uploaded to the wrong tournament - contact support rather than trying to reverse it payment by payment.

The organiser owns the bank relationship and the day-to-day checking:

• signs the agreement with the bank and gives the bank the three pieces of information listed above,
• keeps the account number and KID length in Profixio identical to the bank agreement,
• links the right tournaments to the agreement,
• checks the import list during and after registration, and chases the unmatched lines,
• uploads files by hand where the format has no automatic collection.

Profixio support helps with what you cannot do on these screens. Contact Profixio support to:

• enable the OCR module for the tournament - without it the OCR menu entries do not exist,
• sort out duplicate KID numbers and payments matched to the wrong invoice,
• reverse an import that went to the wrong place.

To see and use the OCR pages at all you need the OCR module enabled for the tournament and tournament administrator or economy rights. A club administrator or team leader never sees these screens - they only see the result in the ledger.

The OCR block disappears from Invoice Settings for tournaments that collect money online through the payment partner - those tournaments do not use OCR.

Work down this list before reporting a fault.

1. Are there any imports at all? Open Economy - OCR kjøring. An empty list, or nothing new for days on an agreement with automatic collection, means files are not arriving - that is a bank agreement or connection problem, not a matching problem. Contact support.
2. Is the tournament linked to the agreement? On OCR avtale, the agreement in use must show the tick in Active for this tournament. A tournament with no agreement gets no KID numbers on its invoices in the first place.
3. Do the invoices actually carry a KID? Open a recent invoice. No KID means the invoice was produced before the agreement was linked; credit it and issue a new one.
4. Does the account number match the bank agreement, digit for digit? This is the most common unnoticed failure: files arrive and are read, but every line stays unmatched.
5. Does the KID length match the bank agreement? Same symptom, same fix.
6. Compare the two counts on the import. If Antall betalinger fil is much larger than Antall lag betaling, the file arrived fine and the problem is per payment - open the import and look at the unmatched rows.
7. Check the KID the club actually used. If a club insists it has paid, ask for its receipt and compare the reference with the KID on its invoice. Paying on another team's KID credits that other team.
8. Is the team invoiced at all? A payment cannot match an invoice that was never created.

If a payment is in the file but on no team after all of this, register it manually from the team ledger so the books are right, and send support the import number and the KID.

OCR matching is built around the Norwegian OCR-giro tradition, and that is where it is fully automatic.

• Norway - Nets (Norway) format. Files are collected from the bank's file post box by Profixio every hour and imported without anyone doing anything. Nothing about it is sport-specific.
• Sweden - BgMax format. The Swedish bank file format is understood and can be imported, but there is no automatic collection: someone has to download the file and upload it manually.
• EU ISO 20022 (RF-0810016). Payment notification files with RF references. Also manual upload only. For this format the IBAN, not the account number, is used to recognise the account.

A practical consequence: on the two manual formats, payments only register as often as somebody uploads a file, so "the team says it paid yesterday and Profixio does not know" is normal there and an alarm signal in Norway.

Whether OCR is used at all is a decision by the organiser and their federation, not something Profixio requires or enforces. Many organisers instead collect money online through the payment partner, in which case OCR is not part of the picture.