A Greek organisation buying myDATA integration should make classification ownership and mapping changes explicit in the software scope. Identify which accountant-approved rule connects each source transaction to the information sent, preserve the mapping version and give exceptions a responsible reviewer. Connectivity alone cannot determine the correct accounting interpretation.
AADE's official ERP integration page describes functions for transmitting invoice information and revenue classifications, retrieving relevant invoice information and submitting expense classifications. These are distinct capabilities that a proposal should identify. Do not assume that a connector advertising myDATA support includes every function your business uses.
TuniCyberLabs serves Greek buyers remotely. This article concerns engineering and operational handover. Your accountant or responsible adviser should determine tax treatment, required classifications, applicable obligations and filing deadlines; the delivery team implements and tests the approved requirements.
Begin with the transaction categories your business actually uses
Consider a fictional business with an online store and a service department. Both create records in the ERP, but their transaction categories and review needs differ. Branch staff use some local labels that do not match the accountant's terminology.
Collect representative source records with sensitive data protected. Include ordinary transactions, refunds or corrections under the approved process, and cases that staff currently resolve manually. Ask the finance owner to explain the intended classification and the evidence needed to decide it.
This creates a practical scope. “Connect the ERP to myDATA” leaves too much unstated: which entities, source modules, transaction categories and review actions must work at launch?
Make the mapping a controlled business artefact
Create a mapping specification that identifies the source field or category, the approved destination meaning, the rule owner and the conditions under which the rule applies. Record unresolved cases rather than assigning a convenient default.
Version the approved mapping. If a rule changes, the system should be able to explain which version was used for an earlier transaction. An administrator changing a dropdown should not silently reinterpret historical records.
Keep the implementation and the business rule review connected. The accountant approves the meaning; the engineer verifies that the code implements it. Neither role should be expected to infer the other's decision from an unexplained field name.
Decide how new products and branches enter the process
A new product category or branch may introduce a source value the connector has never seen. Define the response before launch. The system might pause the affected item for review rather than sending a guessed classification.
Assign who approves a new mapping and how it is tested. Include the relevant business entity and source system so a rule intended for one operation does not automatically spread to another.
For the fictional store, a useful controlled change might start with a new service code. Finance confirms its treatment, engineering adds the mapping and a representative transaction is reviewed in the agreed test process before the rule is used generally.
Preserve the relationship to the source record
The finance team should be able to trace a transmitted item back to the ERP record and the mapping used. Preserve the relevant request and response references under an appropriate access policy.
Avoid treating an external reference as a substitute for the organisation's own record identity. The application needs enough context to investigate when a transaction appears twice, remains unresolved or has a response that staff do not understand.
Design the review screen around that investigation. Show the source record, proposed or transmitted values, mapping version and available outcome. Keep technical details accessible to support without forcing every finance user to read raw payloads.
Separate a data exception from a transport problem
A missing approved classification and an unavailable remote service need different responses. The first belongs with the business rule owner; the second may belong with technical operations. A generic red “failed” label sends both to the same queue and slows resolution.
Define categories such as missing mapping, inconsistent source data, access failure and unresolved transmission outcome according to the actual integration. Give each a next action and owner. Use the provider's documented response meanings rather than inventing success rules.
Do not repeat a business operation automatically merely because a connection was interrupted. Review the documented interface behaviour and preserve enough context to establish the existing outcome before selecting a retry or correction action.
Test the mapping and the connector independently
Have the accountant approve representative inputs and expected business interpretations. Then test that the implementation selects the correct mapping and constructs the expected information. Separately test connection failures and response handling.
Acceptance cases should include:
- ▸A known source category with an approved mapping.
- ▸A source category introduced after the original configuration.
- ▸A transaction associated with a different legal entity.
- ▸Missing information that prevents a justified classification.
- ▸An approved mapping change applied from the intended point.
- ▸A repeated or interrupted transmission requiring investigation.
- ▸A corrected source record whose earlier history remains traceable.
Use the approved environment and examples. Record which scenarios were demonstrated and which remain excluded. A connector should not receive a broad acceptance label after only one ordinary invoice is transmitted successfully.
Reconcile across the business boundary
Ask finance what comparison is needed between ERP activity and the relevant external outcomes. Define the records, period and legitimate differences involved. The purpose is to find actionable gaps, not simply produce a matching total.
For example, a source record with no integration entry requires a different investigation from an entry waiting on a classification review. Keep those categories separate. A reconciliation report that conceals them in one exception count gives the receiving team little help.
Agree how reviewers close an exception and how repeated issues become maintenance work. The organisation should be able to distinguish a process problem, a missing rule and a software defect.
Hand over the mapping process, not only the connector
Request the approved mapping specification, configuration history, test evidence, operating procedures and access ownership. Let the receiving finance and support team investigate a prepared exception during handover.
Establish who follows provider documentation changes and who approves the corresponding business or implementation updates. The application needs a maintained owner after the project team leaves.
Use our CRM and ERP integration scope guide to structure the system boundary and software maintenance agreement guide to define ongoing responsibilities.
Explore software engineering services and request a Greek myDATA integration review. Bring the ERP modules, business entities and classification exceptions your finance team needs to control.