Temsor API — Turkey & EU business data

Quality 57 / 100needs work

43 tools, about 11,703 tokens to load them all · tool set cf50d94bf451 · tools last changed 2026-10-08 · checked 2026-10-19 14:42 UTC

Tool changes

• 2026-10-08tr_vatadded

  Splits a Turkish amount into net, VAT and (optionally) withholding: who pays the seller, who remits the withheld VAT. For invoice lines and checkout totals that have to show KDV dahil / hariç and, when the parties are in a withholding (tevkifat) situation, the split between what the buyer pays the seller and what the buyer remits to the tax office. Rates are 0, 1, 10 and 20 percent. Withholding is a fraction of the VAT (2/10 through 10/10), or a named code from the GİB partial-withholding list. The 2026 threshold (TRY 12,000 gross) is reported and compared with the amount, but `applies` is always null: whether withholding actually applies depends on the taxpayer status of both parties, which this endpoint does not know. Feeding it a fraction is not a legal opinion.

• 2026-10-08tr_validateadded

  Validates Turkish national ID, tax number, IBAN, licence plate, IMEI, barcodes, KEP, MERSİS, postal code and ISBN from one endpoint, with type auto-detection. Goes past a yes/no: resolves the bank behind an IBAN, the province behind a licence plate and the GS1 country prefix behind a barcode. Pure local computation — no upstream service is called, so latency is microseconds and the answer never changes for the same input.

• 2026-10-08tr_tebligat_clockadded

  Computes the deemed-received date and the HMK deadline (with holiday shifting) for a Turkish notification, from the date the underlying event actually happened. Turkish notification law (7201) ties the deadline clock to an event that is not "the date on the letter" — for electronic notification the UETS platform reports send, read AND reached dates, and only the reached date starts the clock (art. 7/a: deemed received 5 calendar days after reaching the address, whether or not it was opened). HMK adds two more rules on top: the day of notification itself does not count (art. 92 — the period starts the next day) and if the computed last day lands on a weekend or a full public/religious holiday, it moves to the next business day (art. 93); a half-day eve (arife) does not shift it. What this will not tell you: whether the notification was itself valid, or what a specific `periodType` (itiraz, temyiz, cevap…) is in days for your case — that number differs by statute and we do not guess it; supply `periodDays` yourself. Only the "hmk" law family is covered so far.

• 2026-10-08tr_qr_odemeadded

  Builds a person-to-person TR Karekod (FAST) payment payload from IBAN, name and optional TRY amount. Text only — no PNG. Turkish instant payments (FAST) can start from a TR Karekod that encodes the payee IBAN and name in EMV-style TLV. This builds the person-to-person organisation (payload format indicator 750210): application template with IBAN, payee name, optional 12-digit kuruş amount, optional free-text explanation, and a CRC-16/CCITT-FALSE trailer. The Turkish IBAN is normalised and checked with ISO 7064 mod-97; non-TR IBANs and non-TRY currencies are rejected. This does not send money and does not render a QR image.

• 2026-10-08tr_posta_koduadded

  Validates a 5-digit Turkish postal code and resolves the province from the first two digits (plate map). PTT postal codes are five digits; the leading pair matches the province plate code for the 81 provinces. This endpoint checks the shape, maps 01–81 to the province name, and returns null with confidence none when the prefix is outside that range — it does not invent a district. District-level resolution needs the full PTT directory and is out of scope here.

• 2026-10-08tr_money_to_wordsadded

  Writes a monetary amount out in Turkish words, the way invoices, cheques and promissory notes require. Applies the rules that trip up generic libraries: Turkish says "bin", never "bir bin"; the kuruş part is read separately; and both "1.234,56" and "1,234.56" are accepted and told apart automatically. A mandatory field on Turkish e-invoices, cheques and notes — with no off-the-shelf API until now.

• 2026-10-08tr_laboradded

  Computes Turkish severance (kıdem), notice (ihbar) and annual-leave entitlement from service dates and the gross wage, using the official ceiling and minimum-wage tables for the given day. Payroll and HR tools in Turkey chase a parameter that changes every January and July: the severance ceiling, the SGK cap, the minimum wage. This endpoint applies the statutory formulae (Labour Law 4857 arts. 17 and 53, former 1475 art. 14) to those tables. The ceiling is applied to the monthly wage, not the total. Stamp tax (0.759%) is deducted from severance; income tax is not — kıdem is exempt. Notice pay IS taxable; we return the gross and say so, because the actual withholding depends on the employee's cumulative tax base. What this will not tell you: whether the employee is entitled to severance at all. That depends on the reason for termination (retirement, just cause, marriage, military service…). Treating the number as "what is owed" is how you lose at trial.

• 2026-10-08tr_invoice_parseadded

  Turns a UBL-TR e-Invoice or e-Archive XML document into clean JSON: parties, line items, taxes and totals. Works regardless of the namespace prefix the sender used (cbc:, cac:, ns0:), normalises single-line documents into arrays, and reports amount mismatches in `warnings` instead of returning quietly wrong totals. The job that costs accounting and expense software the most engineering time.

• 2026-10-08tr_invoice_buildadded

  Builds a UBL-TR e-Invoice or e-Archive XML document from plain JSON, computing every total and validating the parties. Selling into Türkiye means issuing a UBL-TR document whose element order is fixed by schema and whose totals must agree to the kuruş, or the integrator rejects it. This endpoint takes the invoice as ordinary JSON and returns the XML. Totals you send are ignored on purpose — line amounts, per-rate VAT subtotals and the payable amount are all recomputed here, because a rounding difference of one kuruş is the most common rejection. VKN and TCKN checksums are verified, and the amount is written out in Turkish words as invoices require. It does not sign the document and does not transmit it: the financial seal and the submission to the tax authority belong to your certificate and your integrator. What comes back is a document ready to enter that step.

• 2026-10-08tr_iban_olusturadded

  Builds a Turkish IBAN from a 5-digit bank code and account number, computing ISO 7064 check digits. A Turkish IBAN is TR + 2 check digits + 5-digit bank code + 1 reserved digit + 16-character account. This pads the account on the left, defaults the reserved digit to 0, computes the mod-97 check digits, and resolves the bank name from the same national table used by IBAN validation when the code is known. Unknown bank codes still produce a structurally valid IBAN with bankName null — existence at the bank is not claimed.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.