TL;DR
An OCR reference is the invoice number with a check digit on the end, and the check digit is the entire point: the bank rejects a mistyped reference at the moment of payment rather than a fortnight later, and an incoming payment whose reference checks out can be matched to an invoice by a machine instead of a person. The same arithmetic guards your own bankgiro number, which is the field on an invoice with the worst failure mode of any.
Building the reference
Two variants exist in the wild and the bank decides which.
Soft is the number plus a Luhn check digit. Invoice 1043, worked from the right: every other digit is doubled, and anything that reaches ten has nine subtracted from it.
digit 1 0 4 3
doubled no yes no yes
value 1 0 4 6 → sum 11
The check digit is whatever makes the sum a multiple of ten, so 9. The reference is 10439.
Hard inserts a length digit before the check digit, so the bank can also refuse a reference that is the right digits in the wrong quantity. The length digit counts the finished reference including itself and the check digit — for 1043 that is 4 + 2 = 6, and only the last digit of the length fits. The body becomes 10436, whose check digit is 4, and the reference is 104364. Six digits long, exactly as the sixth digit claims.
Why bother with the length variant? A digit dropped in the middle passes Luhn about one time in ten. Length control is what catches the rest.
What Luhn promises, and what it does not
Luhn here is the same algorithm as on a card number, which is why it is worth saying precisely what it does. It catches every single-digit error and almost every transposition of two adjacent digits. That covers the overwhelming majority of what a human types wrong.
It is not a signature. A reference that checks out is a reference that was probably typed correctly, not one that is certainly yours. That distinction decides what the payment matcher is allowed to do on its own, further down.
The awkward edges
Non-digits are stripped. An invoice number of 2026-A-0042 is perfectly ordinary and a bank reference cannot carry the dashes.
Leading zeros go too. They carry no information through a system that treats the reference as a number, and keeping them would only make the length digit lie.
Twenty-five digits is the ceiling. Longer than that and the payment is refused at the bank counter, which is a worse failure than a long invoice number: the customer wanted to pay and could not. So an invoice number too long to carry a reference is refused with a message when the reference is built, not truncated into something that resolves to a different invoice.
A credit note gets no reference at all. Money is never paid into your account against one. Worse, giving it a reference would be actively harmful: invoices and credit notes count on independent series, so credit note 1 and invoice 1 reduce to the same digits and therefore the same OCR. The matcher would find two documents for one incoming payment and have no way to choose.
Your own giro number carries the same check
Bankgiro numbers are seven or eight digits; plusgiro runs from two to eight. Both end in a Luhn check digit — the same arithmetic as the payment reference.
This is the worst field on an invoice to get wrong. A mistyped organisation number is embarrassing. A mistyped giro number is printed on every invoice the company sends, and it either belongs to nobody, in which case payments bounce for weeks, or it belongs to somebody else, in which case they do not. The check digit makes the first outcome certain and the second nearly impossible, which is why it is validated when you type it into settings rather than when a customer's payment fails.
Where the reference travels
In a CAMT.053 statement the reference can be in three places, and they are not equally trustworthy:
- The structured creditor reference. That is the field an OCR number belongs in, and the only one the bank has validated.
- The unstructured remittance lines. Where it usually is instead.
- The bank's own prose about the entry. Read last, because matching on it is matching on a sentence.
Three ways of being right, and only one that posts by itself
An incoming payment is matched in three tiers.
OCR. The reference passes Luhn and resolves to exactly one open invoice. This is as close to certain as the problem gets, and it is the only tier allowed to post a payment without a person.
Invoice number in the message field. Somebody typed carefully, which is usually correct and occasionally last month's invoice number. A proposal.
A unique outstanding amount. A coincidence that is usually not one. Also a proposal.
The reason the last two wait is that posting them automatically is wrong twice over in the same moment: the invoice that was not paid is marked settled and stops being chased, and the customer who did pay is reminded anyway. Of those two mistakes, the second is the one that costs the relationship.
Two details make the number tier behave. Tokens shorter than three characters are ignored — an organisation whose first invoice is numbered 1 would otherwise have it proposed against every message containing a 1, which is most of them. And numbers are matched as whole tokens rather than as substrings, because invoice 42 is otherwise found inside invoice 142 and the wrong one of the two is proposed about as often as the right one.
A line that resolves to two candidates resolves to none, and stays visible with both candidates attached. "One of these three" is much more use to a person than silence.
Getting the statement in at all
None of the matching matters if the file is read loosely, so the import refuses more than it accepts.
CAMT.053 and CSV. The first non-space character decides which — XML opens with a tag and no CSV header does. The filename extension is not consulted, because a CAMT file saved as .csv is ordinary and trusting the extension would parse it as one column.
A bad file is rejected whole, never row by row. A statement imported with one line quietly dropped balances against nothing and is discovered, if at all, by a bookkeeper a quarter later. Failing the import leaves the file on disk and the problem in front of the person who can fix it.
Ambiguous amounts are refused. The string 1,234 is either 1 234 kronor or 1,23 kronor, and the two readings differ by a factor of a thousand. A separator followed by one or two digits is a decimal separator, one followed by exactly three in a number with no other separator is neither, and the file stops there.
ISO dates only. 03/04/2026 is the third of April to half of Europe and the fourth of March to the rest, and a payment booked in the wrong month lands in the wrong VAT period — which is discovered by Skatteverket rather than by you.
A reversal flips the sign. CAMT marks a bounced payment as an entry with the direction undone. Read without that flag it is a second receipt, and the invoice ends up settled by a payment that came straight back.
An entry with no direction is refused outright. Without it the file states an amount and not a direction, and a credit read as a debit settles an invoice out of somebody else's outgoing rent payment.
The same file imported twice is caught. By the bank's own statement identifier where there is one, and by a digest of the bytes where there is not — nobody reviewing a match can tell a genuine second payment of the same amount from a file imported twice.
Statement import and payment matching sit together in the Väx and Pro tiers.
The amount tier and the ROT problem
The amount tier compares against what the customer still owes: the total, less what Skatteverket settles, less what has already come in.
That matters more than it sounds. An invoice totalling 10 000,00 kr with 5 000,00 kr of eligible labour gross carries a 1 500,00 kr ROT deduction, so the customer transfers 8 500,00 kr. Matching on the printed total would find nothing at all — the tier that exists for the customer who transfers exactly the right amount with no reference would miss precisely the invoices where the right amount is not the printed one.
What the invoice prints
Bankgiro and plusgiro in the form the register itself publishes, IBAN and BIC where they are set, the due date, and the OCR reference in its own box in large type. A customer comparing the number on the invoice against the one on their bank screen is comparing the shape as much as the digits.