Polish VAT & Bank Account Checks with Receipt IDs

Check up to 30 supplied invoice/NIP/bank-account/date entries against the Polish Ministry of Finance VAT White List. Each complete receipt includes the NIP profile and a separate authoritative account assignment check, with their two official request IDs retained separately. Export complete rows as JSON or CSV through the Apify dataset. Free KV SUMMARY reports failures, incomplete checks and every original input index.

This is a small payment-batch export for companies with a nonempty 10-digit KRS. Missing KRS produces unsupported_subject_scope; it does not classify the subject as a person. This actor is independent of the Ministry and is not officially endorsed.

{
    "payments": [
        {
            "invoiceReference": "DEMO-INVOICE-001",
            "nip": "7740001454",
            "bankAccount": "PL30102010260000140203550589"
        }
    ],
    "maxResults": 30,
    "requestIntervalMs": 2000
}

payments is required with 1–30 entries before deduplication; total input must fit 32 KiB UTF-8. Unknown fields are rejected. NIP/account must be strings; optional uppercase PL, ASCII spaces and hyphens are normalized and both checksums validated. Invoice references are echoed exactly: nonblank, up to 128 Unicode code points, with no control characters. Per-entry date is optional, defaults to today's date in Europe/Warsaw frozen at run start, and must be a real YYYY-MM-DD between today minus 365 days and today inclusive. Invalid entries never cause source requests; other valid entries can proceed. Invalid top-level input aborts the run.

maxResults is 1–30 (default 30), limiting delivered unique rows. Entries with identical normalized NIP/account/date share one row, with inputIndexes and distinct invoiceReferences in original order. Different accounts for the same NIP/date reuse a successful profile receipt within the run. requestIntervalMs is 1200–5000 (default 1200); the runtime conservatively enforces at least 2000 ms idle after each response, including retries and redirects. Bigger intervals or slow responses may leave a batch incomplete.

Each complete row includes schemaVersion, normalizationVersion, checkKey, recordId, inputIndexes, invoiceReferences, nip, bankAccountNrb, requestedDate, subjectName, krs, vatStatusAsReturned, hasVirtualAccounts, accountAssigned, observationHash, vatStatusTemporalBasis, lookupReceipt, accountCheckReceipt and warnings. Each receipt contains the official requestId, raw requestDateTimeRaw, timeZone:null, independently observed UTC fetchedAt, exact sourceUrl and SHA256 of the raw decoded response bytes. Full source profiles, addresses, PESEL, REGON, people arrays and account lists are excluded from production storage.

accountAssigned is the source's TAK or NIE answer for your supplied pair/date, including virtual accounts. A negative answer is a complete paid receipt. It is never inferred from account-list membership. VAT status is returned as Czynny, Zwolniony or Niezarejestrowany, with vatStatusTemporalBasis: "source_response_unverified". Historical VAT-status semantics have not been independently verified. The two requests are separate observations and are not an atomic government certificate. Source timestamp timezone is unspecified, so it remains raw without conversion, including ambiguous autumn clock hours.

checkKey hashes the normalized pair/date; recordId also includes both official IDs. observationHash covers the eight factual fields, excluding invoice references, times and receipt IDs. Consumers can compare facts across runs: a correction changes the hash, a timestamp-only change does not. Every new run fetches fresh receipts; unchanged results are billable again. Absence or a changed input subset never means deletion. Concurrent runs may duplicate checks and charges; serialize your payment batches.

Pricing uses only two platform built-ins: $0.00005 per Actor start memory unit (one unit through 1 GB) and $0.002 per complete stored unique NIP/account/date receipt, including NIE and unchanged repeat checks. One complete pair at 256 MB has event fees of $0.00205; 30 have $0.06005. No charge per invoice reference, request, retry or hash change. Errors, partial receipts, not-found and unsupported subjects go only to free SUMMARY; the start fee still applies. Platform settings determine the actual invoice.

SUMMARY contains running/final status, started/finished timestamps, requested/valid/unique/delivered counts, observed charged count (nullable), source attempt and byte counters, stop reason, raw Retry-After and deferred time, and per-input outcomes with available official IDs and sanitized diagnostics. Statuses include delivered, invalid_input, not_found, unsupported_subject_scope, partial, error, not_attempted_cap, not_attempted_source_stop and delivery_uncertain. Run status is complete, partial, failed or capped. All original indexes remain visible after a stop. An abrupt kill can leave the last checkpoint incomplete; countersMayBeIncomplete flags recovery from an interrupted run.

OUTPUT is a free KV manifest pointing to SUMMARY and the default dataset, with final status and delivered count. Cloud storage transport retries are disabled so failed push acknowledgments are reconciled by readback.

The free DELIVERY ledger stores at most 30 pending/delivered normalized receipts for same-run recovery. Exact row readback of the listed dataset items confirms delivery, including a stored row with zero charges; the dataset's item count is never trusted, because on the platform it lags a push by seconds. Restart recovery reconciles existing rows before any possible pending push; it never refetches the source. A crash during source work ends further source processing on recovery. Recovery derives the run status again from the reconciled outcomes; a pending receipt confirmed absent that cannot be re-stored within the budget or deadline is reported as not_attempted_cap with spending_cap or deadline. OUTPUT is written after DELIVERY and SUMMARY, so it never claims a status they failed to persist. Invalid state or failed storage updates fail the run and preserve stored rows. There is no cross-run cache, watch baseline, continuation cursor or exactly-once guarantee across runs. Retry unresolved entries as a fresh input, reviewing the dataset first if delivery was uncertain.

Runtime uses only https://wykazpodatnikowvat.mf.gov.pl:443, via anonymous HTTPS GET, no credentials, cookies, browser or proxy. No legacy-host failover. At most one redirect is permitted and must retain the same origin, route, identifiers and date. Work stops immediately on 403, 429, HTML/challenge or unexpected rejection. Retry-After is reported without a same-run 403/429 retry. Transient failures get at most two retries with 2 s then 5 s backoff plus pacing; three exhausted transient failures stop the host.

The published source limits are 100 search requests/day and 5,000 check subjects/day; a block can affect both methods until midnight. Shared-egress enforcement scope and reset timezone are undocumented. A small run can be blocked by earlier shared-IP activity. This single-subject implementation uses at most 60 initial calls for 30 unique suppliers, bounded to 66 total attempts (33 per method), including retries/redirects. Do not assume high-volume daily capacity or rotate egress to bypass a block.

Additional per-run ceilings are 180 seconds work plus up to 10 seconds cleanup, 15 seconds per HTTP attempt, 512 KiB per decoded response, 8 MiB cumulative response bytes, 2 MiB application storage payload traffic, 100 KV reads/writes, 30 dataset writes and 100 dataset reads. Cleanup is reserved before starting more work; repeated checkpoints consume real serialized bytes. Storage ceilings or deadlines can stop before 30 rows. SDK-owned bookkeeping and platform billing/transport overhead require separate platform measurement. No discovery, batch endpoints, persistent monitoring, PDFs, email/webhooks or tax certification.

TAK/NIE does not establish ownership in all contexts, payment execution, payment legality or tax protection. Retain results according to your organization's requirements and consult your own advisers. You control any invoice references and personal data you submit; use references that contain only what you need. Your supplied account is intentionally visible in your private exported receipt. This actor omits unnecessary public personal fields; no exhaustive legal clearance is claimed.

Source: Ministry API documentation and official FAQ. The new host replaced the old default in October 2026. Availability, quota capacity and account assignment may change.