How can we help you?

The law defines which documents must be prepared in XML format: the invoice (including consolidated), credit note, debit note, and tax document for a received advance payment. Self-billing documents can also be issued.

To answer this question, it is necessary to know how this functionality is implemented in the customer's ERP system. The specific solution will be designed during implementation.

To answer this question, it is necessary to know how this functionality is implemented in the customer's ERP system. The specific solution will be designed during implementation.

mib:Peppol can handle all standard supported document types (see the answer on document types). Specific requirements need to be addressed individually.

Attachment functionality will be available.

When an invoice is posted, an e-document is created, and sending only occurs afterwards — either by manual instruction or a scheduled job. The invoice is sent in its current state at that moment. If it was previously cancelled, the e-document is voided and cannot be sent.

The obligation to issue an XML invoice is defined by the VAT Act. XML invoices will also be sent to non-VAT payers — what matters is the existence of a Tax ID (DIČ), not a VAT number (IČ DPH). The system cannot always assess this obligation from available data (e.g., it does not know whether the subject of supply involves classified information), so the final decision rests with the user.

All MLS (Message Level Status) messages related to document transmission — including the Tax Data Document (TDD) for the Financial Administration — will be automatically transferred and recorded in SAP against the relevant document.

mib:Peppol works with self-billing invoices in BIS Self-Billing 3.0 format, which complies with the EN16931 standard and can be transmitted via the Peppol network. EDI self-billing invoices would need to be converted to this format.

This check is only possible after the invoice has been received in SAP (before it is posted). It cannot be performed at the recipient's Access Point, as the Access Point does not have the necessary information.

BT-13 (order reference) is not a mandatory field, so if not provided, the validator will not return an error and the invoice will be delivered. Incomplete invoices must be disputed outside the Peppol network. Invoice corrections are not yet permitted in Slovakia (a change is under consideration). This can be addressed by specifying a Buyer Reference on orders containing the order number. Buyer Reference (BT-10) is also not independently mandatory, but at least one of BT-10 or BT-13 must be provided. If neither is filled in, the validator will return the invoice.

In Slovakia, this situation must be resolved through communication with the supplier (email, phone), who must send a credit note for the invoice via Peppol. A successfully transmitted invoice cannot be changed or cancelled — it can only be credited or debited.

If your system is up to date and your company uses standard SD and FI processes, extensive modifications are not required. However, minor adjustments will be needed for each customer — for example in field mapping, calculation schemes, tax codes, and forms — and the specific system configuration must be reflected in our code. In the final phase, our software developments will need to be transported to your system.

mib:Peppol is a customer API developed according to SAP standards — it therefore does not jeopardize future upgrades. If an upgrade changes a component in use, code adaptation will be required (this applies generally to all SAP upgrades).

To answer this question, it is necessary to know how this functionality is implemented in the customer's ERP system. The specific solution will be designed during implementation after analysing your ERP. The API library does include REST APIs, so robots can in principle be connected this way.

In SAP systems, the invoice or corrective invoice (XML and PDF if included), the Tax Data Document (TDD), the MLS message for the invoice, and the MLS message for the TDD are attached to the e-document and archived according to SAP data archiving settings. In non-SAP systems, the customer handles archiving independently. In the Access Point environment, only document transfer logs are retained, for the period required by OpenPeppol rules.

Sending TDD documents to the Financial Administration's Access Point is mandatory functionality subject to OpenPeppol certification. Its operation is not dependent on any specific customer. The Financial Administration has not yet made such a testing environment available.

mib:Cockpit is connected to its own independent tables, which are populated with data loaded directly from SAP tables.

Yes, we also provide the SAP DRC deployment service at the customer's site. In addition to implementation, we can handle licensing as we are an SAP VAR partner (in the Czech Republic, our sister company MIBCON a.s. provides the same).

Yes, however it is necessary to account for the fact that this represents an extension beyond the basic scope of a standard implementation.

On the Access Point side, performance is scalable according to the required document transfer volumes. Sending from SAP is a separate process and will not slow down bulk processing.

If the XML technical standard changes, it will be a fairly significant change request. Our proposed support model will allow change management to be handled, but in this case it would genuinely be more of a project, as this change will also affect communication with business partners and phasing will need to be addressed (wind-down of original XML, ramp-up of the changed version).

We are currently focused on Slovakia. We then plan to roll out to the Czech Republic (and potentially the entire V4 region as needed) and other OpenPeppol member countries where our customers operate.

Other countries in our CEE region (except Austria) are not yet OpenPeppol members. For Hungary and Poland, only the SAP-side part of our solution can be used, as their national digital communication platforms differ:

• Countries with direct Peppol deployment (Belgium, Slovakia, Latvia, Denmark, Norway, Estonia, Austria, Slovenia, Luxembourg) use the Peppol network directly as infrastructure for invoice transmission.
• Countries with national systems (Italy — SDI/FatturaPA, Poland — KSeF, Hungary — NAV Online) have built their own clearing platforms independent of Peppol, though they may use Peppol for cross-border transactions.

Yes, we plan an information portal with the necessary materials and guides.

We guarantee 99.5% system availability. Given the statutory deadlines for issuing invoices and VAT return dates, this availability is sufficient for retrying. mib:Peppol allows process automation, but this option is not part of the standard solution.

Our solution combines a one-time implementation cost for deploying mib:Peppol with an annual subscription model (SaaS). The annual licence fee is based on the expected volume of transferred documents, with three clear packages available (Basic, Professional, and Enterprise). If you start using the service mid-year, you pay only the proportional part of the annual licence.

No, this type of fundamental change — a change to XML standards in SK/EU — is not included in the base price. If such a change occurs in the future, we intend to notify our customer base of the update's impact in a timely manner and, based on feedback, fairly distribute the associated costs.