Luhn formula¶

The Luhn formula is the decimal modulus-10 check-digit algorithm that alternately doubles digits, reduces two-digit products, and selects a final digit making the transformed sum divisible by ten.

Version: v1 · 2026-09-28 · History
Domain-specific #: 7690
Domain group: Formal Sciences
Origin domain: Mathematics

Core Idea¶

The Luhn formula, also called the Luhn algorithm, modulus 10, or mod 10 algorithm, is a decimal check-digit procedure for detecting accidental errors in identification numbers.^[1] It appends one digit chosen so that a weighted transformation of the complete number has a sum divisible by ten.^[2]

To calculate the check digit, scan the payload from right to left and double every second digit, beginning with the digit in the appropriate alternating position for an appended check digit.^[3] If a doubled value exceeds 9, subtract 9.^[4] Add the transformed and untouched digits, then choose the smallest digit from 0 through 9 that brings the total to a multiple of 10.^[5] Validation repeats the transformation and checks the resulting congruence, or recomputes and compares the check digit.^[6]

The alternating weights make the formula detect every single-digit substitution and almost every adjacent transposition.^[7] It does not detect 09 exchanged with 90, and some paired substitutions also survive.^[8] Leading zero padding leaves the result unchanged when it does not alter the operative parity.^[9] These properties make Luhn useful for quick screening of mistyped account, card, equipment, and government identifiers.^[10]

A successful Luhn check establishes only internal consistency with the numbering rule.^[11] It does not authenticate the issuer, prove that an account exists, or resist deliberate forgery, and it is not a cryptographic hash.^[12] The ordinary Luhn formula is specifically decimal; Luhn mod N generalizes the construction to nondecimal symbol alphabets and is therefore a broader neighboring algorithm rather than an alias for this exact rule.^[13]

Structural Signature¶

Sig role-phrases:

the decimal payload — the ordered digits of the identifier before its Luhn check digit is appended or tested.
the check-digit position — the declared terminal position that fixes the right-to-left parity of all payload digits.
the alternating selection — every second payload digit, counted from the check-digit end, is selected for transformation.
the doubling transform — each selected digit is multiplied by two.
the decimal reduction — nine is subtracted whenever a doubled value exceeds nine, returning a single decimal contribution.
the transformed sum — reduced doubled digits and untouched digits are added under the fixed parity.
the modulus-ten invariant — the check digit is chosen so that the complete transformed sum is divisible by ten.
the validation test — recomputation of the invariant classifies a complete number as Luhn-consistent or inconsistent.
the error-detection profile — every single-digit substitution and most adjacent transpositions disturb the invariant, while known exchanges such as 09 with 90 may not.
the assurance boundary — a passing decimal checksum establishes internal consistency only, not issuer assignment, authenticity, authorization, or cryptographic integrity.

What It Is Not¶

Not any modulus-ten check-digit scheme. The Luhn formula uses a particular alternating doubling rule and decimal reduction; another weighted mod-10 checksum can share the modulus without being Luhn.
Not the general Luhn mod N algorithm. Ordinary Luhn is the decimal construction, whereas Luhn mod N extends related logic to nondecimal symbol alphabets.
Not independent of digit position. Which payload digits are doubled depends on parity counted from the declared check-digit end, so scanning from the wrong end or moving the check digit changes the calculation.
Not a detector of every transcription error. It catches every single-digit substitution and most adjacent transpositions, but exchanges such as 09 with 90 and some paired substitutions can preserve the invariant.
Not authentication or authorization. A number can be deliberately fabricated with a valid Luhn digit; passing only shows internal consistency with the checksum rule, not issuer assignment, account existence, or a presenter's authority.
Not a cryptographic integrity check. The formula is publicly computable and designed for accidental error screening, not resistance to intentional modification or collision attacks.

Scope of Application¶

The Luhn formula applies to decimal identifiers whose issuer has adopted its terminal check-digit convention: alternating right-to-left doubling, subtract-nine reduction, and a transformed sum divisible by ten. Its reach is limited to accidental-error screening and internal consistency; each identifier scheme must separately establish that it uses ordinary Luhn rather than another mod-10 or modified rule.

Payment-card numbers — generate and validate the decimal check digit under the issuer-numbering convention.^[14]
IMEI equipment identifiers — screen entered device numbers for consistency with the adopted Luhn position and parity.^[15]
CUSIP identifiers — apply the relevant Luhn-based check convention while respecting the identifier's declared character handling.^[16]
United States National Provider Identifiers — validate the decimal check digit under the scheme's prescribed Luhn treatment.
National identity and social-insurance numbers — use the algorithm only in jurisdictions whose numbering rules explicitly adopt it.
Tax and corporate identifiers — screen covered decimal reference numbers, including Italian VAT and specified South African or Swedish identifiers.
SIM-card ICCIDs — validate the adopted terminal checksum after preserving the full decimal payload and check-digit position.
European patent application numbers — test internal consistency where the numbering specification assigns a Luhn digit.
Receipt survey and promotional codes — detect common entry errors when the printed decimal code is constructed with ordinary Luhn.
Check-digit generation — compute the smallest final digit that brings the transformed payload sum to a multiple of ten.
Identifier validation — recompute the invariant from a complete number or compare the derived check digit with the supplied one.
Data-entry screening — reject all single-digit substitutions and most adjacent transpositions while retaining known blind spots such as 09/90.
Zero-padded identifier processing — validate before or after leading-zero padding only when the padding preserves parity relative to the check digit.
Implementation conformance testing — expose wrong-end scanning, parity mistakes, missing subtract-nine reduction, or language-specific modulo errors with agreed test vectors.
Checksum-algorithm comparison — distinguish ordinary Luhn from other weighted mod-10 schemes, Verhoeff, Damm, and nondecimal Luhn mod N.
Modified-Luhn numbering systems — document the modification explicitly rather than treating a related postal or issuer-specific rule as an unchanged Luhn instance.

Clarity¶

Passing a Luhn check means that a decimal identifier is internally consistent with one check-digit rule; it does not mean that the issuer assigned it, the account exists, or the presenter is authorized to use it. That distinction keeps transcription screening separate from authentication and cryptographic integrity. A deliberately fabricated number can easily be given a valid Luhn digit.

The name also fixes the alternating parity and decimal scope that informal “mod 10” descriptions can obscure. Whether a digit is doubled depends on its position relative to the check digit, and moving or omitting that position can change every weight. The implementation question is: which characters are the payload, where is the check digit, and does the right-to-left transform yield the required multiple-of-ten congruence? Known blind spots such as 09/90 transposition then remain visible rather than being hidden by a generic claim of error detection.

Manages Complexity¶

Identification schemes vary in issuer, length, grouping, and business meaning, but their decimal transcription check can be reduced to a payload, a check-digit position, an alternating parity, a digit transform, and one modulus-10 remainder. Implementers need not encode separate error logic for every identifier family: scanning from the check-digit end, doubling the designated positions, reducing products above nine, and summing yields either the required check digit or a single validity result.

The same reduction exposes operational branches—generation versus validation, parity changes when the check digit is present or absent, and leading-zero padding that preserves parity—while separating the decimal formula from the broader Luhn mod N construction. Compression stops at the checksum's known error classes. It catches all single-digit substitutions and most adjacent transpositions, but not every transposition or paired substitution, and it says nothing about issuer assignment, record existence, authorization, malicious alteration, or cryptographic integrity.

Abstract Reasoning¶

Luhn reasoning maps a decimal digit string to one modular invariant. From a payload with a declared check-digit position, to the check digit, the algorithm fixes right-to-left parity, doubles alternating digits, subtracts nine from products above nine, and selects the digit that makes the transformed sum congruent to zero modulo ten. Running the same transform in reverse use—from a complete identifier to a validity result—tests consistency with that rule without consulting the identifier's issuer or record system.

Controlled digit changes explain the algorithm's error coverage. From any single-digit substitution to a nonzero change in the transformed remainder, rejection follows; most adjacent swaps also alter the weighted sum because the two positions receive different transforms. The 09/90 exchange and specified paired substitutions provide counterexamples, showing that a valid remainder does not prove faithful transcription. Leading zero padding is neutral only when it preserves the operative parity relative to the check digit.

The abstraction also diagnoses implementation failures. From disagreement between two implementations to the likely fault, the analyst checks whether one included the check digit while choosing parity, scanned from the wrong end, omitted the subtract-nine reduction, or used a different modulo convention. Changing the symbol alphabet moves the problem to Luhn mod N rather than extending the decimal formula silently. Even a correct check establishes neither assignment, existence, authorization, nor resistance to deliberate alteration; those claims require issuer lookup, authentication, or cryptographic controls.

Knowledge Transfer¶

Within identifier validation, the Luhn formula transfers literally across account, card, and reference-number systems that adopt its decimal check-digit convention. The cargo that carries intact is the payload digits, check-digit position, right-to-left alternating parity, doubling transform, subtraction of nine for products above nine, and divisibility-by-ten invariant. Diagnostics transfer by recomputing the check digit, testing a complete identifier, and locating parity or digit-order mistakes.

This is (C) a formal algorithm wherever that exact convention is used. The home-bound cargo is a decimal digit string and its adopted Luhn check position; other modulus-ten schemes may use different weights or transforms. “Passes Luhn” therefore stops at internal consistency with the algorithm. It does not establish issuer assignment, account existence, authorization, authenticity, or resistance to deliberate fabrication, and those claims cannot be imported from the check-digit result.

Examples¶

Canonical¶

Take the example payload 1789372997. Reading from its right-hand end, the alternating positions are doubled: the reversed sequence 7, 9, 9, 2, 7, 3, 9, 8, 7, 1 contributes 5, 9, 9, 2, 5, 3, 9, 8, 5, 1 after products 14 and 18 are reduced by subtracting nine. The contributions of the example payload sum to 56.^[17] The check digit is therefore (10 - (56 mod 10)) mod 10 = 4, making the complete number 17893729974.^[18] Recomputing the expected digit from the payload returns 4, so the supplied terminal digit passes.^[19] The conclusion is only that the number is internally consistent with Luhn; it says nothing about whether an issuer assigned it.^[20]

Mapped back: 1789372997 is the decimal payload, its intended terminal slot is the check-digit position, and the right-to-left choice of every second digit is the alternating selection. Multiplying those digits by two performs the doubling transform; subtracting nine from 14 or 18 performs the decimal reduction. Their total is the transformed sum, while choosing 4 establishes the modulus-ten invariant. Recalculation supplies the validation test, and the limited conclusion respects the assurance boundary.

Applied / In Practice¶

Consider an identifier-processing system that stores a fixed-width decimal field and pads shorter values on the left with zeroes. If it receives the valid example above as 00017893729974, the added zeroes contribute zero and do not move any original digit relative to the check-digit end. The same alternating transformations therefore still produce the expected terminal digit 4. A conformance test should also replace that digit with 5: 00017893729975 must fail because the payload still computes to 4. This pair checks that an implementation counts parity from the declared check-digit end rather than from the left edge of the storage field.^[21] It remains an entry-error screen, not an authentication step.

Mapped back: the padded identifier remains the decimal payload plus the check-digit position; right-relative parity preserves the alternating selection, the doubling transform, and the decimal reduction despite the wider field. The unchanged contributions preserve the transformed sum and the modulus-ten invariant for the version ending in 4, whereas the validation test rejects the version ending in 5. This illustrates the error-detection profile while keeping the assurance boundary explicit.

Structural Tensions¶

T1: Cheap validation versus limited error coverage. Alternating doubling and one modulus-ten test make validation fast enough for routine entry screening, but the same compact invariant leaves known blind spots such as 09/90 exchanges and some paired substitutions. Strengthening detection generally requires a different checksum rather than a more confident reading of a Luhn pass. Diagnostic: test the implementation against both single-digit errors that must fail and named preserving substitutions that may pass.

T2: Right-relative stability versus positional fragility. Counting from the declared check-digit end makes leading-zero padding harmless when it preserves each original digit's parity, yet inserting, deleting, or mislocating a digit can reverse the alternating selection across the payload. The rule is stable under some formatting changes precisely because it is sensitive to position relative to one endpoint. Diagnostic: compare the selected positions before and after a representation change; if original digits switch parity, invariance cannot be assumed.

T3: Public computability versus assurance limits. Anyone can calculate a valid check digit, which makes the formula easy to implement and audit, but also prevents a passing result from establishing authenticity, authorization, or resistance to deliberate alteration. Operational convenience and security assurance therefore pull in opposite directions. Diagnostic: ask whether the decision concerns accidental transcription or an adversarial claim; only the former is resolved by the checksum.

T4: Uniform convention versus scheme-specific adoption. A fixed decimal transform supports common implementations across identifiers that genuinely adopt ordinary Luhn, while issuer-specific character handling, modified rules, or different check-digit positions can make a superficially similar number nonconforming. Interoperability depends on preserving the convention rather than merely sharing the label “mod 10.” Diagnostic: verify the governing numbering specification, payload boundary, and check-digit position before applying a reusable validator.

T5: Binary screening versus explanatory detail. The validation test compresses a full digit sequence to pass or fail, which is useful for rejecting entries but does not identify which digit is wrong or whether a passing identifier exists in an issuer's records. The concise output removes precisely the contextual information needed for repair or authorization. Diagnostic: when a workflow needs correction location or record existence, require an additional diagnostic or lookup rather than inferring it from the Luhn remainder.

T6: Luhn Mod N Algorithm reduction versus Luhn-formula autonomy. The domain-specific immediate parent abstraction Luhn Mod N Algorithm strictly subsumes the formula: every qualifying Luhn-formula computation is a declared-alphabet check-symbol procedure within that generalized family. The child remains in situ because it fixes decimal digits, parity-dependent doubling, subtract-nine digit reduction, modulus ten, and a characteristic error profile. Reduction gains the portable alphabet–transform–residue architecture but erases the decimal obligations; complete autonomy hides the general check-symbol genus. Diagnostic: if the decimal alphabet and its exact doubling, reduction, and modulus rules are removed while a Mod N check-symbol algorithm remains, Luhn Mod N Algorithm survives but the Luhn Formula does not.

Structural–Framed Character¶

Luhn Formula is structural-leaning. Its evaluative_weight is low: pass and fail are formal consequences of the transformed sum, while the practical decision to use that result only for transcription screening belongs to the surrounding identifier system. Its human_practice_bound character is low-medium because people choose an identifier scheme and check-digit position, but the alternating transform and modulus-ten invariant remain mechanically determinate once those inputs are fixed. Its institutional_origin is medium: standards and issuers establish where ordinary Luhn applies, yet their authority does not determine the calculation's result. Its vocab_travels judgment is low-medium: payload, check digit, parity, and validation recur among checksum algorithms, whereas the Luhn name and subtract-nine decimal rule remain specific. Its import_vs_recognize profile is recognition-dominant: one can identify the procedure directly from its digit transformation and congruence rather than conferring it through an institutional judgment.

The exact in-domain umbrella is Luhn Mod N Algorithm, which preserves the alphabet–position–transform–residue architecture while allowing nondecimal alphabets and profiles. The smallest positively reviewed portable skeleton is Algorithm: admissible input is carried through a finite, definite sequence to a terminating check-digit or validity result. Removing that procedural skeleton destroys both levels; removing the decimal alphabet, alternating doubling, subtract-nine reduction, and modulus-ten obligation leaves Algorithm and the domain parent intact but not Luhn Formula. The cross-domain reach belongs to that Prime.

Its character: a formally recognizable decimal algorithm with a narrow standards frame, structurally portable through Algorithm but individuated by its exact Luhn transform and checksum convention.

Structural Core vs. Domain Accent¶

Luhn Formula is a domain-specific strict specialization of Luhn Mod N Algorithm: it fixes the general check-character scheme to decimal symbols, modulus ten, and a particular alternating transform. Both levels instantiate the Prime Algorithm, whose finite input-to-output procedure is the portable skeleton.

What is skeletal (could lift toward a cross-domain prime). Algorithm supplies admissible inputs, a finite and definite sequence of steps, controlled branches, termination, an output, and a correctness claim bounded to stated preconditions. That complete signature recurs in at least three unrelated domains—for example, Euclid's procedure computes a greatest common divisor, a routing algorithm selects paths through a network, and an administrative allocation algorithm assigns scarce resources under declared rules. Luhn Mod N realizes the skeleton with an ordered alphabet, positional selection, symbol transformation, modular accumulator, and check-character solver; the decimal child retains all of those roles.

What is domain-bound. The immediate domain parent supplies payload symbols, check position, parity rule, transformed contribution, modular total, completion symbol, and validation residue. Luhn Formula further fixes the alphabet to digits zero through nine, the modulus to ten, selection to alternating positions from the check-digit end, and the transform to doubling with subtract-nine reduction. Its error profile, leading-zero behavior, and boundary from authentication or cryptographic hashing also remain specific. Remove only these decimal restrictions and Luhn Mod N survives; remove the parent procedure and no Luhn checksum remains.

Why this does not clear the prime bar. Stripping checksum and alphabet vocabulary leaves Algorithm's input–steps–termination–output structure, already complete across unrelated domains; stripping only decimal commitments leaves the exact in-domain parent rather than a new Prime. Conversely, retain a decimal identifier but remove the alternating transformation or modular completion rule, and the result is not the Luhn Formula. The two removal directions establish strict subsumption at both levels: the general Luhn scheme is complete without modulus ten, while the child requires the exact decimal transform and check-digit convention.

This entry is a kind of Luhn Mod N Algorithm.

Immediate domain parent — Luhn Mod N Algorithm (Luhn Mod N Algorithm). Luhn Formula strictly instantiates the general check-character scheme with the ordered alphabet fixed to decimal digits, N fixed to 10, the selected-position operation fixed to doubling followed by subtract-nine reduction, and a terminal digit chosen to complete the zero congruence. Remove those decimal restrictions and the broader Luhn Mod N carrier, parity, transformation, accumulator, and solver remain; remove the alternating transform or modular completion and the decimal child no longer qualifies.

Instantiates — Algorithm (Algorithm). The payload is an admissible input; alternating selection, doubling, reduction, summation, and modular completion form a finite, definite, mechanically executable procedure; check-digit generation or validity is the output; and completion of the scan supplies termination. The correctness claim is bounded to the stated decimal checksum and error profile. Replacing the decimal data and steps with another finite input-to-output procedure erases Luhn Formula while Algorithm survives, whereas removing definite steps, termination, or result destroys both the child and this mapping.

The Algorithm relation is inherited through the exact immediate domain parent and has also passed direct full-signature comparison here.

Relationships to Other Abstractions¶

Current abstraction Luhn formula Domain-specific

Parents (1) — more general patterns this builds on

Luhn formula is a kind of Luhn Mod N Algorithm Domain-specific

Luhn Formula strictly instantiates the general check-character scheme with the ordered alphabet fixed to decimal digits, N fixed to 10, the selected-position operation fixed to doubling followed by subtract-nine reduction, and a terminal digit chosen to complete the zero congruence.

Hierarchy paths (2) — routes to 2 parentless roots

Luhn formula → Luhn Mod N Algorithm → Algorithm → Function (Mapping)

Show alternative path (1)

Neighborhood in Abstraction Space¶

Luhn formula sits in a sparse region of the domain-specific corpus (86^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2551 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

Luhn mod N. Luhn mod N generalizes the check-symbol construction to nondecimal alphabets, whereas the ordinary Luhn formula fixes decimal digits and modulus ten. Tell: if symbols outside 0–9 are transformed under an N-symbol alphabet, the calculation belongs to the generalized parent.
A generic mod-10 checksum. Many schemes make a weighted sum divisible by ten without using Luhn's alternating doubling and subtract-nine reduction. Tell: verify the right-relative parity and exact digit transform, not the modulus alone.
The Verhoeff algorithm. Verhoeff is a separately named, more complex check-digit algorithm described as detecting more transcription errors than Luhn, not the ordinary Luhn formula. Tell: require Luhn's right-relative alternating doubling, subtract-nine reduction, and modulus-ten invariant rather than classifying a decimal check digit by purpose alone.
The Damm algorithm. Damm is a separately named, more complex check-digit algorithm described as detecting more transcription errors than Luhn, not the ordinary Luhn formula. Tell: require Luhn's right-relative alternating doubling, subtract-nine reduction, and modulus-ten invariant rather than classifying a decimal check digit by purpose alone.
A cryptographic hash or message authentication code. Cryptographic mechanisms are designed to resist intentional modification or forgery, while Luhn cheaply screens common accidental entry errors. Tell: anyone can recompute a valid Luhn digit without a secret.
Issuer or account validation. A correctly formed checksum does not show that an identifier was assigned, exists, is active, or belongs to its presenter. Tell: those claims require an authoritative lookup or authentication beyond the modular test.
Credit-card authorization. Authorization evaluates an actual payment request under issuer and account controls; a Luhn pass only checks number syntax. Tell: separate recomputing the terminal digit from contacting the payment system.
The check digit itself. The final digit is the output stored in an identifier, whereas the formula is the transformation and congruence rule that generates or validates it. Tell: a digit value without payload, position, and parity does not specify the algorithm.
A left-anchored alternating-weight rule. Luhn parity is fixed relative to the declared check-digit end, so left padding can be harmless while inserting a digit elsewhere is not. Tell: determine doubled positions from the right-hand check slot rather than the display field's left edge.
Complete transcription-error detection. Luhn catches every single-digit substitution and most adjacent swaps but has known blind spots such as 09 with 90. Tell: a passing remainder is internal consistency, not proof that no digits were transposed or jointly altered.

References¶

[1] United States Postal Service, Publication 199: Intelligent Mail Package Barcode Implementation Guide (source). registry ↩

[2] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[3] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[4] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[5] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[6] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[7] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[8] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[9] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[10] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[11] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[12] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[13] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[14] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[15] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[16] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[17] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[18] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[19] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[20] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩

[21] Unverified encyclopedia synthesis; no authoritative source located for the claim as written. ↩