Tax Declarations Service

The Tax Declarations service enables calling applications to generate the SAF-T XML file (Standard Audit File for Tax) required for mandatory tax reporting to Bulgarian and Romanian tax authorities.

Access info

Usage

Prerequisites

• The organization(s) for which reporting is done must exist in the SBS system. You can add new organizations either from the SBS Portal or programmatically by calling the Organizations Service.
• The organization object in SBS must contain at least the following fields: name, tin (Tax Identification Number), regNo (registration number issued by the National Trade Registration Office), country, streetAddress, ibanNumber, taxAccountingBasis.
• For Bulgarian tax declarations, the organization’s ownership structure must be defined (ownershipStructureBG) in accordance with the rules laid out for elements S.O.1 through S.O.11 in the SAF-T Schema. You can define these fields when creating or updating the organization, either from the SBS Portal or programmatically by calling the createOrganization or updateOrganization mutations of the Organizations Service.
• You must prepare several CSV files to be used as input to te Tax Declarations service. The exact set of files depends on the audit file country and the tax residence status of the reporting organization. Typically, an API caller generates or exports the CSV files from an ERP system. For details, see:
  • Appendix 1: Input CSV Files (Romania Tax Residents)
  • Appendix 2: Input CSV Files (Romania Non-Residents)
  • Appendix 3: Input CSV Files (Bulgaria Tax Residents).

SAF-T Schema

Bulgaria

The SAF-T schema files for Bulgaria can be downloaded from https://nra.bg/wps/portal/nra/proekti/sistema-za-schetovodno-otchitane/sistema-za-schetovodno-otchitane.

Romania

The Romanian National Agency of Fiscal Administration (ANAF) has published (and periodically updates) an Excel sheet which contains information about the structure of the SAF-T file, field validation rules and format, as well as valid codes required for specific field types. The file is called “Schema Fișierul Standard de Control (Standard Audit File – SAF-T)” and will be subsequently referred to as the SAF-T Schema in this documentation.

To locate the SAF-T schema on ANAF website (https://anaf.ro), navigate to Despre ANAF > Strategii ANAF > Proiecte de digitalizare > SAF-T and look for the most recently published version of the “schema xls” file.

Generating a declaration

To generate a declaration:

1. Obtain from your ERP system the input CSV files to be used as input to the tax declaration. For the structure of each file, see:

   • Appendix 1: Input CSV Files (Romania Tax Residents)
   • Appendix 2: Input CSV Files (Romania Non-Residents)
   • Appendix 3: Input CSV Files (Bulgaria Tax Residents).

2. Create a representative through a call to the createRepresentative mutation.

3. Initiate a declaration through a call to the initiateDeclaration mutation. As a result, a new declaration object is created, and the response contains the unique declaration ID. You will need to work with this declaration ID in subsequent steps to further process the declaration and monitor its status.

4. Add all the input CSV files to the declaration. See Preparing declaration files.

5. Run the generateDeclaration mutation. This triggers a computation that takes place from several minutes to several hours, depending on the size of input CSV files. In either case, the outcome, including any possible errors, is reported in the returned Process object. If the computation was successful, the response includes a download URL at which you can download the generated XML file.

Preparing declaration files

After you have initiated the declaration, you can add all the CSV input files to it.

For each input CSV file, the steps are as follows:

• Run the prepareFile mutation. In the response, you get the file’s upload URL at which you can upload the actual file.
• In the programming language of your API, make an HTTP PUT request to upload the file content to the upload URL. This step is similar to how you would create a file and then upload its content in the File Management Service, as described in the Tutorial: Create a file.

Note that you can add multiple files of the same type for the same declaration. For example, you can add several input CSV files of type “Invoices”. If multiple files of the same type exist, SBS will aggregate and compute data found in all respective files.

After adding all the CSV files, you can check if they are indeed attached to the declaration by running the declarations query, for example:

query declarations ($filter:DeclarationsFilter!, $processFilter:ProcessesFilterInput) {
  declarations(filter:$filter) {
    id
    organization { id, name, tin }
    representative { id, firstName, lastName, phone, email }
    headerComment 
    from
    to
    files { id, fileType, name, createdAt }
    createdAt
  }
}

{
  "filter": {
    "id": "YOUR_DECLARATION_ID",
    "organizationId": "YOUR_ORGANIZATION_ID"
  }
}

If your declaration looks good so far, you can proceed to running the generateDeclaration mutation, for example:

mutation generateDeclaration($declarationId:ID!) {
  generateDeclaration(declarationId:$declarationId) {
    id
    status
  }
}

{
    "declarationId": "YOUR_DECLARATION_ID"
}

Dealing with large input files

As mentioned above, when you add a file to the declaration, there are two steps involved:

1. Run prepareFile and obtain the upload URL.
2. In the programming language of your API, make an HTTP PUT request to upload the file content to the upload URL.

For the second step, note, however, that the maximum file size that you can send in a single PUT request is 5 GB. Should you need to add larger files to the declaration, you can do so through the multipart upload mutations provided by the File Management Service. In this scenario, the process looks as follows:

1. Run prepareFile and take note of the data.prepareFile.id returned in the response body. This ID corresponds to a file id of a file in File Management Service.
2. Provide the id above as input to the initiateMultipartUpload mutation and continue with the rest of steps required for multipart upload, as described in Uploading large files.

Processes

Each time when you run generateDeclaration, a new process with status NEW is attached to the declaration. You can view the declaration and the status of all its processes by running the declarations query and requesting the processes field in the response, for example:

query declarations ($filter:DeclarationsFilter!) {
  declarations(filter:$filter) {
    id
    processes{
      id,
      status,
      errorMessages,
      totalSegmentsInSequence,
      createdAt,
      result {
        id
        name
        createdAt
        downloadUrl(expiresIn:3600)
      }      
    }
    createdAt
  }
}

{
  "filter": {
    "id": "YOUR_DECLARATION_ID",
    "organizationId": "YOUR_ORGANIZATION_ID"
  }
}

The status of any process is initially NEW. The status NEW will normally change to INPROCESS after approximately 1 minute. Note that, if you run generateDeclaration multiple times for the same declaration, each run will start a new process for the same declaration. In this case, you will need to track the status of each process separately. The processes field of the declarations query provides a filter (by process ID) for that purpose.

The INPROCESS status of a process may take from a few minutes to a few hours, depending on the size of the input CSV files. After the INPROCESS status, the status may change to either ERROR (if errors are encountered) or DONE (upon successful processing).

If the status ERROR is encountered, check the errorMessages response field of the respective process for details.

If the process completes with status DONE, it generates a result XML file whose download URL is available in the result response field of the respective process. Also, the totals counters of the declaration object are now populated with data as computed from the input CSV files.

Additionally, when the process status is DONE for a monthly Romanian D406 declaration, the roD406AnalysisData field of the process is populated with financial KPIs. This data is also accessible directly via the roD406AnalysisData query.

If necessary, you may stop a running process through a call to killProcess. However, this is possible only if the process has not generated any results (that is, if the result field of the process is empty).

You may also delete a process through the deleteProcess mutation. Deleting a running process is possible only if the process has generated no result yet.

Deleting declarations

You can delete declarations through a call to deleteDeclaration. Note, however, that it is not possible to delete a declaration if it has at least one running process that has already generated some result file. To delete such a declaration, you will need to wait for the process to finish first.

Validation

Validation of data provided as input to the Tax Declarations service takes place at two levels:

1. A first validation takes place after you submit the generateTaxDeclaration mutation. This validation is performed by the SBS API. Any errors encountered at this stage are reported in the errorMessages attribute of the returned Process object.
2. A second level of validation is provided by the DUK Integrator tool available for download from the ANAF website (https://anaf.ro). The same tool is used to generate the PDF (including the signed XML SAF-T file) that is to be submitted to ANAF. To download the tool, navigate to Despre ANAF > Strategii ANAF > Proiecte de digitalizare > SAF-T and look for the latest available version of the validator.

In addition to the two validation levels above, ANAF defines a set of consistency tests that are not necessarily covered by the DUK Integrator tool. For Romanian D406 declarations, the results of these tests are returned in the validations field of ROD406AnalysisData, as a list of ROD406Validation objects.

These consistency tests have recommendation status only: because some of them can yield false positives in situations to which they do not apply, a failed test does not prevent a declaration from being generated or submitted, and is surfaced for your awareness.

The tests are as defined in the following ANAF communiqués:

• Set 1: comunicat_saft_teste_v2.pdf
• Set 2: testedeconsistenta2.pdf

How to view the results of ANAF consistency tests

The consistency tests are evaluated together with the RO D406 analysis data when you generate a Romanian D406 declaration, so no separate request is needed to run them. Once the declaration has been computed, you read the results from the validations field of ROD406AnalysisData.

To obtain the consistency-test results for a declaration:

1. Generate the declaration as described in Generating a declaration, and take note of the process id returned by the generateDeclaration mutation.
2. Wait for the process to reach status DONE. You can poll the process status through the declarations query, as shown under Processes.
3. Once the process is DONE, call the roD406AnalysisData query with the organization ID, declaration ID, and process ID, requesting the validations field. Until the analysis data has been computed, the query returns null.
4. Inspect each returned ROD406Validation object. The status indicates the outcome of the test (SUCCEEDED, FAILED, or SKIPPED). For a FAILED test, the message field carries the failure reason; a SKIPPED test may also carry a message explaining why the test did not apply.

Remember that these results are informational only: a FAILED consistency test does not prevent the declaration from being generated or submitted.

Example

query roD406AnalysisData($organizationId:ID!, $declarationId:ID!, $processId:ID!) {
  roD406AnalysisData(
    organizationId: $organizationId
    declarationId: $declarationId
    processId: $processId
  ) {
    validations {
      code
      description
      status
      message
    }
  }
}

{
  "organizationId": "YOUR_ORGANIZATION_ID",
  "declarationId": "YOUR_DECLARATION_ID",
  "processId": "YOUR_PROCESS_ID"
}

A declaration returns the full standard list of tests. The description field is the test description as published in the ANAF communiqués (in Romanian), while the message field for a FAILED or SKIPPED test is in English. A sample response, abbreviated to one test of each status, looks as follows:

{
  "data": {
    "roD406AnalysisData": {
      "validations": [
        {
          "code": "1.1",
          "description": "În secțiunea Header, subsecțiunea Header Structure - Company - Company Header Structure - Adress - verificarea completării câmpurilor City și Country",
          "status": "SUCCEEDED",
          "message": null
        },
        {
          "code": "1.5",
          "description": "În secțiunea Master File, subsecțiunea General Ledger Accounts verificarea completării câmpurilor: Account ID, Account description, Account Type, Opening Debit/Credit Balance, Closing Debit/Credit Balance",
          "status": "FAILED",
          "message": "29 account(s) missing required fields (AccountID, AccountDescription, AccountType, or balance fields)"
        },
        {
          "code": "1.14",
          "description": "În secțiunea Master File verificarea soldurilor finale (Closing Debit Balance și Closing Credit Balance) ale lunii să coincidă cu soldurile inițiale (Opening Debit Balance și Opening Credit Balance) ale lunii următoare",
          "status": "SKIPPED",
          "message": "Single-period declaration (period null/null): cross-period validation requires data from consecutive declarations"
        }
      ]
    }
  }
}

Queries

declarations

Lists the declarations defined for the given tenant. The results of their computation processes can be found in the corresponding declaration process list.

Arguments

DeclarationsFilter input

Result

Declaration type

Representative type

File type

ProcessesFilter input

Process type

ROD406AnalysisData type

ROD406Profitability type

For formulas, see Appendix 9.

ROD406Liquidity type

ROD406Activity type

ROD406TaxAnalysis type

ROD406AssetAnalysis type

ROD406StandardBalanceSheet type

The standard balance sheet maps the organization’s account balances to the standard chart of accounts prescribed by the tax authority for the corresponding tax accounting basis.

ROD406StandardBalanceClass type

ROD406StandardBalanceAccount type

ROD406SystemBalanceSheet type

The system balance sheet provides the organization’s actual (system-of-record) account balances, as opposed to the standard balance sheet, which maps balances to the standard chart of accounts prescribed by the tax authority. Both balance sheets are populated only for monthly (HeaderComment = L) or quarterly (HeaderComment = T) Romanian D406 declarations.

ROD406SystemBalanceClass type

ROD406SystemBalanceAccount type

ROKPIAnalysisDataElement type

Provides the RO D406 KPI analysis for a single month of the reporting period. A process returns one element per month covered by the declaration.

ROD406Validation type

Represents the outcome of a single ANAF consistency test applied to the analysis data. These tests are the additional checks ANAF requires that are not covered by the DUK Integrator tool described under Validation.

ResultFile type

Totals type

CsvFileLines type

AccountTotal type

DebitCreditOpenClose type

DebitCredit type

CsvInvoiceTotals type

CsvPaymentTotals type

CurrencyAmount type

MasterFilesTotals type

GeneralLedgerAccountsTotals type

BusinessPartnersTotals type

GeneralLedgerEntriesTotals type

SourceDocuments type

InvoicesTotals type

PaymentsTotals type

Header type

CompanyHeaderStructure type

Address type

ContactHeaderStructure type

PersonNameStructure type

TaxIdStructure type

BankAccount type

SelectionCriteriaStructure type

Example

query declarations ($filter:DeclarationsFilter!, $processFilter:ProcessesFilterInput) {
  declarations(filter:$filter) {
    id
    organization { id, name, tin }
    representative { id, firstName, lastName, phone, email }
    headerComment 
    from
    to
    files { id, fileType, name, createdAt }
    processes (filter: $processFilter) {
      id, 
      status, 
      errorMessages,
      createdAt,
      result { id name createdAt downloadUrl(expiresIn:3600) },
      totals {
          csvLines {
              generalLedgerAccounts
              businessPartners
              assets
              physicalStock
              generalLedgerEntries
              invoices
              payments
              movementOfGoods
              assetTransactions
              allFileLines
          }
          csvBusinessPartnerAccountTotals {
              accountID
              debitCredit {
                  totalDebitOpen
                  totalDebitClose
                  totalCreditOpen
                  totalCreditClose
              }
          }
          csvGeneralLedgerAccountsMonthTotals {
                totalDebitOpen
                totalDebitClose
                totalCreditOpen
                totalCreditClose
          }
          csvGeneralLedgerEntriesMonthTotals {
              totalCredit
              totalDebit
          }
          csvInvoiceTotals {
              allInvoices
              customerInvoices
              supplierInvoices
              customerInvoicesTotal
              supplierInvoicesTotal
              customerInvoicesCurrencyTotal {
                  currency
                  amount
              }
              supplierInvoicesCurrencyTotal {
                  currency
                  amount
              }
          }
          csvPaymentTotals {
              allPayments
              debitPayments
              creditPayments
              debitTotal
              creditTotal
              debitCurrencyTotal {
                  currency
                  amount
              }
          }
      },
    }
    createdAt
  }
}

{
  "filter": {
    "id": "YOUR_DECLARATION_ID",
    "organizationId": "YOUR_ORGANIZATION_ID"
  }
}

declaration

Retrieves a single declaration by its identifier.

Arguments

Result

See the Declaration type.

Example

query declaration($id:ID!) {
  declaration(id:$id) {
    id
    organization { id, name, tin }
    representative { id, firstName, lastName, phone, email }
    headerComment
    declarationType
    from
    to
    files { id, fileType, name, createdAt }
    processes { id, status, createdAt }
    createdAt
  }
}

{
  "id": "YOUR_DECLARATION_ID"
}

organizations

Returns a list of active organizations defined for the given tenant.

Result

The result is an array of Organization.

Organization type

Example

The following query retrieves the currently active organizations defined in the Organizations Service.

query Organizations {
  organizations {
    id
    name
    tin
    regNo
    country
    createdAt
 }
}

representatives

Returns a list of representatives created for the given tenant.

Arguments

None.

Result

See the Representative type.

Example

The following query retrieves all the representatives.

query representatives {
  representatives {
    id
    firstName
    lastName
    phone
    email
    otherTitles
  }
}

roD406AnalysisData

Returns comprehensive RO D406 analysis data for the month for which the declaration was computed. Currently, this query retrieves data only for declarations that use monthly (not quarterly) reporting.

The analysis data is computed together with the declaration and no extra steps are required to generate it, apart from generating the RO D406 declaration itself, see Generating a declaration.

Arguments

Result

Returns ROD406AnalysisData, or null if not yet computed.

Example

query roD406AnalysisData($organizationId:ID!, $declarationId:ID!, $processId:ID!) {
  roD406AnalysisData(
    organizationId: $organizationId
    declarationId: $declarationId
    processId: $processId
  ) {
    from
    to
    currency
    periodDays
    profitability { CA EAT EBT EBIT EBITDA MB MPN RCT VE CT }
    liquidity { CR DAT CL }
    activity { NFC NFF VMF NPC RRC RAC RRF }
    tax { TVAC TVAD TVAN }
    assets { VBI AMP RAI }
    standardBalanceSheet {
      classes {
        id name
        openingDebit openingCredit currentDebit currentCredit closingDebit closingCredit
        accounts {
          id name
          openingDebit openingCredit currentDebit currentCredit closingDebit closingCredit
        }
      }
    }
    systemBalanceSheet {
      openingDebit openingCredit currentDebit currentCredit closingDebit closingCredit
      classes {
        id name
        openingDebit openingCredit currentDebit currentCredit closingDebit closingCredit
        accounts {
          id standardId name
          openingDebit openingCredit currentDebit currentCredit closingDebit closingCredit
        }
      }
    }
    validations { code description status message }
  }
}

{
  "organizationId": "YOUR_ORGANIZATION_ID",
  "declarationId": "YOUR_DECLARATION_ID",
  "processId": "YOUR_PROCESS_ID"
}

roKPIAnalysisData

Returns historical RO D406 KPI analysis data, broken down by month. Applicable only for declarations that use monthly (not quarterly) reporting.

To obtain KPI data:

1. Initiate a Romanian declaration with a call to initiateDeclaration. Set declarationType to KPI.
2. Set the from and to dates for the period you want to cover (for example, the past 3 years up to current date).
3. Set the headerComment to L (Monthly).
4. Add the GeneralLedgerAccounts and GeneralLedgerEntries CSV files to the declaration (for the latest month) with prepareFile, as described in Preparing declaration files.
5. Trigger the computation with generateDeclaration and note the id of the returned Process.
6. Once the process reaches status DONE, call roKPIAnalysisData with the organization ID, declaration ID, and that process ID. Until then, the query returns null.

NOTE: No SAF-T XML file is generated when you set the declarationType to KPI.

Arguments

Result

Returns a list of ROKPIAnalysisDataElement objects, one per month of the reporting period, or null if not yet computed.

Example

query roKPIAnalysisData($organizationId:ID!, $declarationId:ID!, $processId:ID!) {
  roKPIAnalysisData(
    organizationId: $organizationId
    declarationId: $declarationId
    processId: $processId
  ) {
    month
    profitability { CA EAT EBT EBIT EBITDA MB MPN RCT VE CT }
    liquidity { CR DAT CL }
    activity { NFC NFF VMF NPC RRC RAC RRF }
    tax { TVAC TVAD TVAN }
  }
}

{
  "organizationId": "YOUR_ORGANIZATION_ID",
  "declarationId": "YOUR_DECLARATION_ID",
  "processId": "YOUR_PROCESS_ID"
}

version

Returns the API version.

Mutations

createRepresentative

Creates a record identifying the person that submits the tax declaration. Once a representative is created, it can be referenced multiple times by different declarations.

Arguments

CreateRepresentativeInput input

Result

See the Representative type.

Example

mutation createRepresentative($input:CreateRepresentativeInput!) {
  createRepresentative(input:$input) {
    id
    firstName
    lastName
    email
    phone
    otherTitles
  }
}

{
  "input": {
    "firstName": "Miroslav",
    "lastName": "Radomirov",
    "phone": "999-999-999",
    "email": "miroslav@example.org",
    "otherTitles": "Chief Finance Officer"
  }
}

deleteDeclaration

Deletes a declaration, including all its input files and related processes.

Arguments

Result

See the Declaration type.

Example

mutation deleteDeclaration($id:ID!) {
  deleteDeclaration(id:$id) {
    id
  }
}

{
  "id": "YOUR_DECLARATION_ID"
}

deleteFile

Deletes a previously uploaded CSV file.

Arguments

DeleteFileInput input

Result

See the File type.

Example

mutation deleteFile ($input:DeleteFileInput!) {
  deleteFile(input: $input) {
    id
    declarationId
    fileType
    name
    createdAt
  }
}

{
    "input": {
        "declarationId": "YOUR_DECLARATION_ID",
        "id": "YOUR_FILE_ID"
    }
}

deleteProcess

Deletes a declaration computation process and the result XML files.

Arguments

Result

See the Process type.

Example

mutation deleteProcess($declarationId:ID!, $processId:ID!) {
  deleteProcess(declarationId:$declarationId, processId:$processId) {
    id
    status
    errorMessages
    result {
        id
        # downloadUrl
        createdAt
    }
    createdAt
  }
}

{
    "declarationId": "YOUR_DECLARATION_ID",
    "processId": "YOUR_PROCESS_ID"
}

deleteRepresentative

Deletes a previously created representative.

Arguments

Result

See the Representative type.

Example

mutation deleteRepresentative($id:ID!) {
  deleteRepresentative(id:$id) {
    id
    firstName
    lastName
    phone
    email
  }
}

{
    "id": "REPRESENTATIVE_ID"
}

generateDeclaration

Starts a declaration computation process.

Arguments

Result

See the Process type.

Example

mutation generateDeclaration($declarationId:ID!) {
  generateDeclaration(declarationId:$declarationId) {
    id
    status
    errorMessages
  }
}

{
    "declarationId": "YOUR_DECLARATION_ID"
}

initiateDeclaration

Creates a new tax declaration, without triggering any computation processes. After this mutation, run prepareFile for each CSV file that must be supplied as input to the declaration and obtain the file’s upload URL. After uploading the CSV files, run generateDeclaration mutation to trigger the computation process.

Arguments

InitiateDeclarationInput input

Result

See the Declaration type.

Example

The following mutation initiates a tax declaration, where:

• The declaration type is SAFT
• The declaration is for a monthly period (M)
• The declaration’s reporting period is 2025-01-01 through 2025-01-31.
• The audit file country is BG (Bulgaria)
• The region code is BG01 (Благоевград)
• The company’s tax accounting basis is A.

mutation initDecl($input: InitiateDeclarationInput) {
  initiateDeclaration(input:$input) {
    id
    organization { id, tin, name }
    representative { id, firstName, lastName }
    declarationType
    headerComment
    taxAccountingBasis
    from
    to
    files { id, fileType }
    processes { id, status }
    createdAt
  }
}

{
  "input": {
    "declarationType": "SAFT",
    "from": "2025-01-01",
    "to": "2025-01-31",
    "organizationId": "YOUR_ORGANIZATION_ID",
    "representativeId": "YOUR_REPRESENTATIVE_ID",
    "regionCode": "BG01",
    "headerComment": "M",
    "taxAccountingBasis": "A",
    "auditFileCountry": "BG"
  }
}

killProcess

Stops a declaration computation process if it is running.

Arguments

Result

See the Process type.

Example

The following mutation stops a running process.

mutation killProcess($declarationId:ID!, $processId:ID!) {
  killProcess(declarationId:$declarationId, processId:$processId) {
    id
    status
    errorMessages
    result {
        id
        downloadUrl
        createdAt
    }
    createdAt
  }
}

{
    "declarationId": "YOUR_DECLARATION_ID",
    "processId": "YOUR_PROCESS_ID"
}

prepareFile

Generates a URL at which you can upload a CSV file to be used as input to the tax declaration. Run this mutation for each CSV file that is to be supplied as input for a declaration.

Arguments

PrepareFileInput input

Result

See the File type.

Example

The following mutation generates the upload URL for a file of type “BusinessPartners”. The upload URL is set to expire after 300 seconds.

mutation prepareFile($input:PrepareFileInput!) {
  prepareFile(input:$input) {
    id
    declarationId
    fileType
    name
    uploadUrl(expiresIn:300)
    createdAt
  }
}

{
  "input": {
    "declarationId": "YOUR_DECLARATION_ID",
    "fileType": "BusinessPartners"
  }
}

updateDeclaration

Update certain declaration parameters.

Arguments

UpdateDeclarationInput input

Result

See the Declaration type.

Example

The following mutation updates the tax accounting basis of an existing declaration to A.

mutation updateDecl($id:ID!,$input:UpdateDeclarationInput) {
        updateDeclaration(id:$id,input:$input) {
          id
          organization { id name tin }
          representative { id firstName lastName phone email }
          headerComment
          declarationType
          taxAccountingBasis
          auditFileCountry
          from
          to
          regionCode
          files { id fileType }
          processes { id status }
          createdAt
        }
      }

{
    "id": "YOUR_DECLARATION_ID",
    "input": {
        "taxAccountingBasis": "A"
    }
}

updateRepresentative

Updates a previously created representative.

Arguments

UpdateRepresentativeInput input

Result

See the Representative type.

Example

The following mutation updates a representative’s details.

mutation updateRepresentative($id:ID!, $input:UpdateRepresentativeInput!) {
        updateRepresentative(id:$id, input: $input) {
          id
          firstName
          lastName
          email
          phone
          otherTitles
        }
      }

{
    "id": "REPRESENTATIVE_ID",
    "input": {
        "firstName": "John",
        "lastName": "Doe",
        "phone": "999-999-999",
        "email": "john.doe@example.org",
        "otherTitles": "Accounting Manager"
    }
}

Webhooks

The Tax Declarations Service supports webhooks. This means you can optionally configure SBS to send an HTTP POST request to an external server or application whenever any of the following events occur:

• COMPUTATION_SUCCESS - fires whenever a tax declaration was generated successfully.
• COMPUTATION_ERROR - fires whenever a tax declaration was generated with errors.

The POST request of the COMPUTATION_SUCCESS event has the following payload:

{
  "service": "tax-declarations-api",
  "event": "COMPUTATION_SUCCESS",
  "tenantId": "<your-tenant-id>",
  "payload": {
    "declarationId": "<your-declaration-id>",
    "processId": "<your-process-id>"
  },
  "customKey1": "Custom value 1",
  "customKey2": "Custom value 2"
}

The POST request of the COMPUTATION_ERROR event has the following payload:

{
  "service": "tax-declarations-api",
  "event": "COMPUTATION_ERROR",
  "tenantId": "<your-tenant-id>",
  "payload": {
    "declarationId": "<your-declaration-id>",
    "processId": "<your-process-id>"
  },
  "customKey1": "Custom value 1",
  "customKey2": "Custom value 2"
}

Note that the customKey1 and customValue1 will be present in the request body only if you configured them when creating the webhook. You may configure as many key-value pairs as required.

For information about configuring webhooks, see Webhooks.

Appendices

Appendix 1: Input CSV files (Romania Tax Residents)

When preparing the CSV files to be used as input to the Tax Declarations service, keep in mind the following:

• Each CSV file is comma-separated;
• The first row in the CSV file should provide the column names (that is, the CSV file must include the header);
• The fields described in the tables below are validated by ANAF according to the type described in the “Format” column. For details about each type, refer to the SAF-T Schema. More specifically, for simple types, you can find the validation rules in the “Simple Types” sheet. For the list of valid codes of various fields, consult the “Centralizator nomenclatoare” sheet.

GeneralLedgerAccounts.csv

BusinessPartners.csv

GeneralLedgerEntries.csv

Invoices.csv

If the reporting organization needs to report self-billing invoices (autofactura) to itself, use either of the following ses, set InvoiceType to 389.

Option 1 — Set the customer to the company’s own Tax Registration Number (TIN):

• Set CustomerID to the reporting company’s own TIN, and leave SupplierID empty. A leading RO prefix is optional and ignored when matching, so both RO12345678 and 12345678 are accepted.
• This form is recognized only when InvoiceType is 389. A CustomerID equal to the company TIN on any other invoice type is still rejected, because the TIN does not correspond to a business partner of type C.

Option 2 — Leave the customer and supplier empty:

• Set both CustomerID and SupplierID to an empty value. When both values are empty, the system considers the reporting organization to be the customer (or supplier, depending on the case).
• Set SelfBillingIndicator to 389.
• For all movements having the same TransactionID in the GeneralLedgerEntries.csv file, ensure that both CustomerID and SupplierID also have an empty value.

Payments.csv

PhysicalStock.csv

MovementOfGoods.csv

Assets.csv

AssetTransactions.csv

Appendix 2: Input CSV files (Romania Non-Residents)

To submit a non-residents tax declaration for Romanian tax authorities, the input parameters must be set as follows:

• auditFileCountry should be RO
• taxAccountingBasis should be I.
• headerComment should be NL or NT.

For such declarations, the following input CSV file types are required:

• GeneralLedgerAccounts
• BusinessPartners
• Invoices

The files may be empty (i.e., contain only the header) if no business activity took place within the reported period.

When preparing the CSV files to be used as input to the Tax Declarations service, keep in mind the following:

• Each CSV file is comma-separated;
• The first row in the CSV file should provide the column names (that is, the CSV file must include the header);
• The fields described in the tables below are validated by ANAF according to the type described in the “Format” column. For details about each type, refer to the SAF-T Schema. More specifically, for simple types, you can find the validation rules in the “Simple Types” sheet. For the list of valid codes of various fields, consult the “Centralizator nomenclatoare” sheet.

GeneralLedgerAccounts.csv

BusinessPartners.csv

Invoices.csv

Appendix 3: Input CSV files (Bulgaria Tax Residents)

When preparing the CSV files to be used as input to the Tax Declarations service, keep in mind the following:

• Each CSV file is comma-separated;
• The first row in the CSV file should provide the column names (that is, the CSV file must include the header);

GeneralLedgerAccounts.csv (BG)

BusinessPartners.csv (BG)

GeneralLedgerEntries.csv (BG)

Invoices.csv (BG)