ポーランドNIPチェックディジット
9桁の526104082のチェックディジットは8で、NIPは526-104-08-28になります。9桁を入れれば番号を完成でき、10桁を入れれば打ち間違いや数字の入れ替わりを請求書や取引先の登録前に見つけられます。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- Nip
- 526104082
- 計算モード
- Compute
- 入力
- 526104082
- チェックディジット
- 8
- チェックディジット付き
- 5261040828
- 整形済み
- 526-104-08-28
末尾の1桁は、ポーランド税務システムで使われる標準の剰余規則に従い、先頭9桁の固定重み付けから導かれるチェックディジットです。1桁の誤入力や入れ替わりでもチェックサムが崩れることが多いため、請求書の発行、仕入先の登録、パートナーファイルの受領前にNIPを検証すると、多くの入力ミスを早期に検知できます。本機能は9桁の本体（一般的なハイフンの有無は問いません）からポーランドNIPのチェックディジットを計算するか、末尾桁を含む完全な10桁番号を検証し、桁を勝手に捏造せず不正入力を報告します。
ポーランドNIPチェックディジットとは何か、重みの仕組み
NIPはポーランドの税務・商業・行政フローで納税者と法人を識別します。印刷フォームではXXX-XXX-XX-XXのようにハイフンで桁を区切ることが多いですが、実体は常に10個の十進数字です。先頭9桁が本体で、10桁目は公開されたチェックアルゴリズムで完全に決まり、納税者が自由に選べるものではありません。
公式の重み付けは、左から右へ6・5・7・2・3・4・5・6・7を各桁に掛けます。積を合計し、その合計を11で割った余りが候補のチェックディジットです。余りが0から9ならその値がチェックディジットとなり、整形式のNIP文字列が完成します。
余りが10の場合、その本体に対する単一の十進チェックディジットは存在せず、標準規則では有効なNIPとして割り当てられません。この特別ケースにより、台帳照会の前でも、ランダムな9桁列が実在の税番号として現れないことがあります。
決済カードで使うLuhn mod-10と比べ、NIPは左から右の固定重みベクトルとmod 11を使うため、ポーランド税務ID欄にLuhn検証を流用してはいけません。スペインDNIの文字表やアルゼンチンCUITの重みと比べても、ポーランドNIP規則はこの10桁レイアウトと9個の乗数に固有です。
どの方式が必要かを把握しておけば、汎用チェックディジットツールが整形式でないNIPを受け入れても誤った安心を避けられます。本ツールは任意のハイフンと空白を除去したうえで、純粋な数字に標準重みを適用します。政府ポータルへの照会、企業の実在証明、種別コードの割当は行わず、公開アルゴリズムのもとで桁列が一貫していることだけを確認します。
税務・請求・商流におけるポーランドNIPチェックディジットの位置づけ
電子請求・課金システムは法的文書ごとに顧客・仕入先のNIPを保持します。オンボーディングでの1桁の誤入力が、誤った相手への税務XMLや後続の認可失敗につながることがあります。B2B注文でポーランド企業税IDを集めるECチェックアウトは、外部台帳なしでチェックディジットを再計算し、OCRノイズや部分キャプチャを早期に除外できます。
給与・会計・CRM取込はスプレッドシートからパートナーNIPを受け取り、末尾桁の誤りがバッチ全体を拒否することがあります。一般的なLuhnやISO 7064ツールを既に公開している製品チームも、ポーランド税務ID欄には重み・桁数・ハイフン形式がドメインに合う本NIP専用機能を使うべきです。「
polish nip check digit」や「poland nip validator」相当の教育・SEOランディングには、自動化と一致するライブ無料ツールが必要で、チュートリアルのスクリーンショット精度を保てます。どのワークフローでも契約は同じです。
NIPチェックディジットの合格を、人物・企業の正しい識別、税務署での稼働、請求権限、公式台帳への存在の証明と見なさないでください。証明するのはポーランドNIPチェックアルゴリズムのもとで桁列が一貫していることだけです。
活用例
パートナー・請求ファイルのNIP列を監査する
CSV取込の各NIPを一括検証し、チェックディジットが再計算の期待値と一致しない行を隔離してください。
よくある質問
ポーランドNIPのチェックディジットはどう計算しますか？
先頭9桁に重み6, 5, 7, 2, 3, 4, 5, 6, 7を掛け、積を合計し、合計を11で割った余りを取ります。余りが0–9ならそれがチェックディジット、10ならその本体は有効なNIP基数ではありません。
computeとvalidateの違いは何ですか？
computeは9桁を受け取り、チェックディジットと完全な10桁NIPを返します。validateは末尾桁を含む10桁を受け取り、再計算したチェックディジットと一致するかを返します。
チェックディジットが間違っているとどうなりますか？
validateでは期待桁がある場合は応答に含まれ、validはfalseになります。
チェックディジットが存在しない9桁の番号があるのはなぜですか？
重み付きの合計を11で割った余りが10になると、1桁の数字では補えないためです。その本体は有効なNIPにならないので、ツールは数字を作らずにその旨を知らせます。
NIPが有効なら会社は実在しますか？
いいえ。有効という結果は、10桁が公式の検査規則に合っていることを示すだけです。政府の窓口や会社の登録簿は照会しないため、納税者が誰かは確認できません。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/enc/nip-poland \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"nip":"526104082"}'const res = await fetch("https://api.kit.forhosting.com/enc/nip-poland", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"nip": "526104082"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/nip-poland",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"nip": "526104082"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/nip-poland", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"nip":"526104082"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"nip":"526104082"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/nip-poland", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"nip": "526104082"
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.nip_poland",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
ポーランドの納税者識別番号（NIP、Numer Identyfikacji Podatkowej）は、請求書、企業登記、給与ファイル、ECの税務フィールドで使われる10桁のコードです。ブラウザでは無料、公開価格のKIT APIでも同じ決定的な算術を実行し、ネットワーク照会や実在納税者の台帳照会は行いません。
チェックディジットの計算と完全なNIPの検証方法
ハイフンや空白で区切っても構いません。validateモードは末尾チェックディジットを含む完全な10桁（例：5261040828または526-104-08-28）を期待します。空文字、nip欠落、不正なmode、誤った桁数は重み付き合計の前に失敗し課金されません。既知の9桁本体からNIPを組み立てるときはcompute、ユーザー・パートナーファイル・スキャンラベルが完全番号を渡し、台帳やマスタ照会の前に真偽ゲートが必要なときはvalidateを選んでください。0から9の数字を含むnipフィールドを送信してください。文字、その他の句読点、二重ハイフン、先頭・末尾のハイフンは malformed として invalid_input で拒否され、静かに正規化された値を受け入れることはありません。既定のcomputeモードでは、チェックディジットを除くちょうど9桁（例：526104082、またはハイフン付き9桁本体）を渡し、エンジンは1文字のcheck_digit、その桁を含む完全な10桁with_check、一般的な表示形式XXX-XXX-XX-XXのformattedを返します。重み付き合計のmod 11が10の場合、その本体に有効な末尾桁がないためcomputeはinvalid_inputで失敗します。再計算したチェックディジットが最終桁と一致すればvalidはtrueとなり、常にcheck_digit、最終桁を除くpayload、weighted_sum_mod11、formattedを含み、有効な期待桁がある場合はexpected_check_digitも返します。時計・乱数・ネットワークのない純粋parseのため、同じ入力は無料ブラウザツールとAPIで常に同じJSONになります。成功リクエストあたり$0.002で、仕入先の一括取込、オンボーディングフォーム、ETLジョブをゲートでき、個別ティア交渉は不要です。
税務・請求・商流におけるポーランドNIPチェックディジットの位置づけ
入口のvalidateはvalidがfalseのとき保存を止め、expected_check_digitを示して記録前に修正できます。validとwith_checkを返す決定的オラクルにより、本番前に行をフラグできます。
連携の活用例
仕入先・顧客フォームのNIP欄をゲートする
ユーザーが完全なポーランドNIPを送ったらvalidateを呼び、validがfalseなら保存を止め、expected_check_digitを示してERP記録前に1桁の誤入力を直してください。
ID完成時に末尾桁を計算する
9桁本体からcomputeを呼び、with_checkまたはformattedを保存して、印刷・エクスポート・請求書生成前に正しい末尾桁を付与してください。
技術的な質問
ハイフンと空白は使えますか？
はい。一般的な区切りは解析前に除去されます。文字、その他の句読点、壊れたハイフンパターンはinvalid_inputで拒否されます。
ポーランドNIPチェックディジット計算機の料金は？
ブラウザツールは無料です。APIは成功コールごとに前払いKIT残高$0.002を使い、不正入力は課金されません。