Our Products

mm.erp — GİB e-Ledger Signing

Sign e-Ledgers directly with your financial seal; no Ma3Api required.

Sign in to the app Guide Quote / support request

Key features

Direct financial-seal signing

GİB e-Ledger files are signed directly with the financial seal; no middleware to install.

No paid SDK

We build the signing library ourselves; no Ma3Api or other paid SDK licence is needed.

In production, tested

Signs real e-Ledger packages in production.

Journal, ledger and Berat

Signs GİB e-Ledger Journal (Yevmiye), General Ledger (Kebir) and Berat XML files in XAdES-BES format; the output has the structure GİB's validators expect.

Accountant and company signatures

A Supplier or Accountant role is embedded in each signature; for files that need two signatures the statutory order (Accountant first, then Supplier) is followed.

Wherever your key lives

A USB e-Seal token, the Windows certificate store (including remote desktop / virtual machines) and a PFX file for testing are all used the same way.

Independent verification after signing

Besides a fast cryptographic check, a comprehensive validation that reports the structure step by step, including schema and KamuSM root certificate chain checks.

Embeds in your software

Called directly from your own software as a .NET library; the command-line tool covers batch and manual jobs. No separate signing service is required.

Product documentation

Overview

Our in-house mm.erp.tr library signs Turkish e-Defter (e-Ledger) files directly with the qualified electronic seal, with no paid SDK in between. In production use.

Signing engine

XAdES-BES, GİB-compatible

  • Produces a XAdES-BES envelope (signed properties, signature info, key info) for Journal, Ledger and Berat XML files.
  • The output is bit-level compatible with the Ma3Api signature format and is accepted as valid by the GİB e-Ledger web service validator and the GİB e-Ledger Viewer.
  • The software has no dependency on Ma3Api.
  • Details learned from real GİB rejection and acceptance cases (canonicalisation method, signature encoding, reference order, line-ending normalisation) are built into the engine.

Key sources

  • USB e-Seal token: through the PKCS#11 driver; the private key never leaves the device.
  • Windows certificate store: for remote desktop and virtual machines where the token stays on the client side.
  • PFX/P12 file: for development, testing and offline jobs.
  • The signature algorithm follows the key strength (SHA-256, SHA-384, SHA-512 for P-256, P-384, P-521 respectively).

Verification

Two-level checking

Signed files are verified at two levels:

  • Fast cryptographic verification: recomputes the digests and the signature to check them.
  • Comprehensive verification: reports seven steps separately for each signature: format, identification of the signing certificate, certificate chain (against the KamuSM root list), cryptographic verification, signature acceptance and obsolete-algorithm checks. The result per signature is passed / failed / indeterminate.

Schema and rule checks

  • GİB e-Ledger and XAdES schema validation.
  • Running the GİB schematron rules.
  • A helper that repairs common defects (encoding, period boundary, MimeType).
  • Chain validation against the KamuSM trusted root certificate list.

Catches errors before signing

  • When using a token, the match between key and certificate is tested automatically before signing starts; a wrong pair does not come back days later as a GİB rejection.
  • With several devices or keys it does not guess; in case of ambiguity it stops and lists the available options.
  • If the session drops (token removed, connection lost) it reconnects and retries once; operation errors such as a wrong PIN are not retried, so the token is not locked.
  • The PIN can be supplied from an environment variable, an encrypted file or hidden prompt instead of being typed openly on the command line.

Library and command line

  • Called directly from your own application; no separate process is required.
  • Command-line tool: signing with PFX, token and the Windows certificate store; fast and comprehensive verification; listing installed PKCS#11 drivers and certificate providers.
  • The signing role (Supplier or Accountant) is embedded in each signature.
  • Targets .NET 10 only; the library is backed by unit tests.

Scope

mm.erp is for signing and verifying e-Ledger files. Calls to the GİB web service (SOAP) need a separate signature layer and are outside the scope of this product. For details and suitability, fill in the quote form.

Today vs. with mm.erp — e-Defter Signing

e-Ledger signing

Today (manual / spreadsheets)Signing needs an intermediate layer or a paid development kit; the dependency chain grows.

With mm.erp — e-Defter SigningJournal, ledger and berat files are signed directly with the financial seal as XAdES-BES; no paid kit is needed, and it is used as a .NET library or from the command line.

Seeing a rejection in advance

Today (manual / spreadsheets)A key–certificate mismatch is only learnt days later as a GİB rejection.

With mm.erp — e-Defter SigningThe key and certificate pairing is tested before signing; two-level verification (fast cryptographic plus full step by step) checks the schema, schematron and the KamuSM root chain.

Seal environment and roles

Today (manual / spreadsheets)The seal only works plugged into one computer; signing over remote desktop or on a virtual machine gets hard.

With mm.erp — e-Defter SigningA USB token, the Windows certificate store (remote desktop/virtual machine included) or a PFX for testing is used; Supplier and Accountant roles sign in the required order.

How does pricing work?

Pricing depends on the modules you use and on the number of users and companies. Try it free first or ask for a short live demo; once the scope is clear, we send a written quote.

  • We are with you during installation and initial setup.
  • No credit card or payment details needed for the trial.
  • The quote states the scope, number of users and support period clearly.
Try it free Live demo Get a quote

Install in 3 steps

  1. 1. Choose your key source

    A USB e-seal token, the Windows certificate store or (for testing) a PFX file; all go through the same signing interface.

  2. 2. Sign the file

    Sign the Journal, Ledger or Berat XML file from the library or the command line and specify the role (Supplier/Accountant).

  3. 3. Verify and submit

    Verify the signed file in fast or comprehensive mode; if the result is positive, it is ready to go to GİB.

Frequently asked questions

Which files does it sign?

It signs GİB e-Ledger Journal, General Ledger and Berat XML files in XAdES-BES format.

Which key sources are supported?

A USB e-Seal token (PKCS#11), the Windows certificate store and a PFX/P12 file for testing.

Can it be used on a remote desktop or virtual machine?

Yes. When the token stays on the client side PKCS#11 may not see it; in that case the Windows certificate store path is used.

How do I verify a signed file?

With a fast cryptographic check or a comprehensive verification that reports seven steps; schema and schematron checks are also available.

How can I try it?

Fill in the quote form and we will walk through the signing and verification flow together using sample files.

Works well with

Financial Compliance Bundle

e-Ledger signing, e-Tax return automation and e-Document design: the full set of Revenue Administration (GİB) processes from one provider.

All solution bundles

Keep me informed

Choose how you would like to hear about mm.erp — e-Defter Signing: news by email, or a call from us.

How would you like to be informed? (one or both)

Trial, demo or quote

What would you like?

Ideas and suggestions

Would you like a feature in mm.erp — e-Defter Signing, have a suggestion or hit a problem? Tell us; the team reads every message and shapes the roadmap accordingly.

Type

Name and email are optional; leave an email if you would like us to get back to you.