The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →For Turkish e-Fatura, a useful local XML validator needs more than a successful parse: it should check well-formed XML, validate against the applicable UBL-TR XSD files, and run the matching Schematron rules. In JavaScript, treat those checks as separate stages, use the official artifacts for the document’s profile, and record exactly which artifact set produced the result. A local pass is a conformance check—not proof of signature validity, sender identity, GİB acceptance, or legal sufficiency.
What an e-Fatura XML validator must check
UBL-TR is the Turkish customization of UBL used for these invoices. GİB’s e-Arşiv Technical Guide v1.17 (May 2024) describes UBL-TR as the general invoice format and says the data must conform to published schema and Schematron rules. That is the key implementation distinction: XSD validation checks document structure and data types, while Schematron can enforce additional business constraints.
Do not assume that every XML document using UBL, or every Turkish invoice case, uses the same rules. Define the document family and profile your validator accepts, then select the corresponding official XSD and Schematron artifacts. GİB’s public-sector e-Fatura Technical Guide v1.5 adds requirements and examples for its public-sector context; those additions should not be treated as universal e-Fatura rules.
Establish the rule set before writing the validator
Pin the applicable GİB artifacts
Obtain the currently applicable UBL-TR package and its associated XSD and Schematron files from GİB’s technical materials. The exact authoritative package release is not established here, so do not label a validator “current” or “GİB-compliant” based on an assumed version. Record the package version if published, retrieval date, and cryptographic hashes of the files you deploy. Keep the files with the release of your application that uses them.
#1 Best Overall
Resolve schema imports and includes from that controlled local package. Do not allow invoice input to choose a remote schema location or cause validation-time network requests. If the package changes, treat it as a rule-set change: review the diff, run regression fixtures, and retain the validation result’s package identifier.
Keep profile-specific rules scoped
The public-sector guide illustrates why profile selection matters. Its example Schematron includes an abstract PayeeFinancialAccountIDCheck that checks for a Turkish IBAN-shaped value: the value begins with TR, followed by seven digits and seventeen alphanumeric characters. It also shows a BuyerCustomerPartyCheck requiring one VKN identification whose value is ten digits. These are examples in that guide’s public-sector additions; confirm the applicable profile and current package before enforcing them elsewhere.
The same public-sector material shows checks involving UBLVersionID, CustomizationID, ProfileID, invoice ID, invoice type, and currency code. Such checks illustrate how Schematron can add constraints to structural validation; the authoritative rule is the one in the applicable current package, not a copied rule fragment.
Rank #2
Design the JavaScript validation pipeline
1. Define an explicit input contract
Specify whether callers submit a byte buffer, a file, or an already decoded string; whether one request may contain multiple invoices; and which UBL-TR profiles are supported. For reproducibility, profile selection should be an explicit input or a documented, deterministic result of inspecting the document—not an undocumented default.
2. Parse XML safely
Use a namespace-aware XML parser and stop immediately if the input is not well-formed. Do not parse XML with regular expressions: prefixes can vary, namespaces affect element identity, and XML nesting cannot be handled reliably that way. For untrusted input, disable external entity resolution and network access, impose limits on input size and nesting depth, and avoid resolving imports from user-controlled locations. These are defensive implementation measures, not special GİB rules.
Parser security settings differ among JavaScript runtimes and libraries. Confirm the behavior of the parser you select rather than assuming a browser or Node.js parser has the same protections. Do not pass an unsafe document to the XSD or Schematron stage after parse failure.
3. Run XSD validation against the pinned package
Pass the parsed XML to a validator that supports the actual XSD set, including its imports and includes. JavaScript may orchestrate a native or WebAssembly validator, a controlled Java or .NET sidecar, or a validation service. The choice depends on deployment constraints, compatibility with the official artifacts, diagnostics, throughput, and memory needs. No particular npm package’s completeness or maintenance against GİB’s Schematron suite is established here; verify any candidate against the official package before relying on it.
4. Run the corresponding Schematron rules
Run Schematron only after parsing succeeds, and ordinarily after XSD validation so that malformed structure is not confused with a business-rule failure. Use the Schematron files that belong to the same applicable package as the schema. Preserve each reported rule identifier, message, severity if available, and source location. Do not substitute a handful of copied checks for the complete profile-specific ruleset.
Free tools Windows power users keep installed
One-click scans. No signup required.
5. Return separate, actionable outcomes
Keep parse, XSD, Schematron, and any optional signature or transport results distinct. This makes it clear whether a document is malformed, structurally invalid, or rejected by a business rule, and avoids implying that a structural pass verifies other parts of the workflow.
Rank #4
async function validateInvoice(input, profile, adapters, ruleSet) {
const parsed = await adapters.xml.parseSafely(input);
if (!parsed.ok) {
return {
valid: false,
profile,
ruleSet: ruleSet.id,
parse: parsed,
xsd: { status: "not-run", diagnostics: [] },
schematron: { status: "not-run", diagnostics: [] }
};
}
const xsd = await adapters.xsd.validate(parsed.document, ruleSet.xsd);
const schematron = await adapters.schematron.validate(
parsed.document,
ruleSet.schematron
);
const hasErrors = [xsd, schematron].some(stage =>
stage.diagnostics.some(item => item.severity === "error")
);
return {
valid: !hasErrors,
profile,
ruleSet: ruleSet.id,
parse: { status: "passed", diagnostics: [] },
xsd,
schematron,
signature: { status: "not-checked" },
transport: { status: "not-checked" }
};
}This is orchestration pseudocode: parseSafely, xsd.validate, and schematron.validate are adapter contracts, not built-in JavaScript APIs. Define your own stable diagnostic shape, and ensure every adapter reports errors consistently. If warnings are possible, keep them separate from errors rather than silently treating them as either success or failure.
Build tests around profiles and package versions
Keep fixtures for each supported profile and rule-set release. Include successful documents and deliberate failures so that both validators and your diagnostic mapping are exercised.
- Malformed XML and namespace-prefix variations.
- Missing required elements, invalid dates or amounts, currency cases, and duplicate identifiers.
- Known XSD failures and known Schematron failures, with expected rule IDs or diagnostic locations where the validator provides them.
- Public-sector IBAN and VKN cases only when the public-sector supplement is in scope.
When the official package changes, rerun the fixtures against the new artifacts and compare the outcomes. Keep regression results tied to the package identifier and application release so that an earlier validation decision can be reproduced.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWhat a successful local pass does not establish
GİB’s stated assurance scope includes format and standards conformance, sender identity, validity, and content integrity. Parsing, XSD validation, and Schematron validation address conformance checks; they do not, by themselves, establish all of those other assurances. Where the workflow requires signed data, implement signature and certificate checks as an explicit stage with a defined trust policy.
Local validation is also separate from transmitting an invoice, processing a response, archiving it, or obtaining approval to integrate. GİB’s Special Integration Guide v1.12 describes integration as a broader process involving system preparation, documentation, application, and completion of an integration process. A validator is one component of that system, not a substitute for it.
Keep e-Arşiv requirements distinct
The e-Arşiv Technical Guide v1.17 (May 2024) is evidence for its e-Arşiv case, not a universal definition of e-Fatura profiles. It specifies ProfileID as EARSIVFATURA for that case and discusses XAdES-BES for signed data. It also describes a particular PDF route in which UBL-TR XML is attached and must conform to schema and Schematron under the guide’s stated conditions. Do not transfer those profile or signature details to a different invoice flow without checking the applicable GİB material.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →
