Changelog. What shipped, when.

AzoraOne now supports processing of customer invoices through a dedicated extraction and bookkeeping workflow that mirrors how supplier invoices are handled.

We've added customer invoice processing to AzoraOne, including extraction with customised GL coding and bookkeeping entry submission for continuous learning - the workflow follows the same pattern as supplier invoices. Customer identification relies on master data managed through the new customer endpoints. Your application can now automate accounts receivable processing using the same integration pattern you already know.

Customer master data must be set up through the customers endpoints before extraction is performed. Extraction accuracy depends on the completeness of this data, including name, VAT number, legal registration identifier and tags.

Affected Operations:

GET {api}/{version}/companies/{companyID}/files/{fileID}/customerInvoices

Extract data and customised GL coding from an uploaded file, with optional extended properties including dates, currencies, VAT numbers and country of origin.

PUT {api}/{version}/companies/{companyID}/files/{fileID}/customerInvoices

Submit bookkeeping entries for a processed customer invoice to contribute to continuous learning.

Customer data can now be managed using the same design already in place for supplier data.

AzoraOne now supports customer data management through six new dedicated endpoints. You can store and maintain identifiers such as legal registration numbers, VAT numbers and customer tags to help AzoraOne match customers accurately during customer invoice extraction. This gives your application a structured foundation for accounts receivable flows.

Affected Operations:

POST {api}/{version}/companies/{companyID}/customers

Create a new customer record under the specified company.

POST {api}/{version}/companies/{companyID}/customers/multiple

Create multiple customer records for the specified company in a single request.

GET {api}/{version}/companies/{companyID}/customers

Retrieve all customer records associated with the specified company.

GET {api}/{version}/companies/{companyID}/customers/{customerID}

Retrieve a single customer record by its ID within the specified company.

PUT {api}/{version}/companies/{companyID}/customers/{customerID}

Update the properties of an existing customer record within the specified company.

DELETE {api}/{version}/companies/{companyID}/customers/{customerID}

Delete a customer record from the specified company.

Patterns allow your users to define explicit identifier-based routing rules that take effect independently of AzoraOne's self-learning mechanism, giving your users deterministic control over recurring document sorting.

The new patterns resource introduces deterministic document routing to AzoraOne, letting your users attach identifiers to a destination so that matching documents are sorted to the correct type automatically. Until now, sorting relied entirely on self-learning; patterns give your users a way to encode known rules and override that flow where needed. Identifiers are words AzoraOne looks for in uploaded documents to decide where to route them; the destination specifies the document type (i.e. CustomerInvoice, SupplierInvoice, Receipt or Other) and optionally verification series. Full CRUD operations are available at the company level.

The verification series in a destination is optional. If omitted, AzoraOne routes the document to the specified type without applying a series. Patterns are company-scoped and do not carry over between companies.

Affected Operations:

GET {api}/{version}/companies/{companyID}/patterns

Retrieve a filtered, pageable list of sorting patterns for a given company.

GET {api}/{version}/companies/{companyID}/patterns/{patternID}

Fetch the full details of a single sorting pattern by its ID.

POST {api}/{version}/companies/{companyID}/patterns

Create a new sorting pattern with one or more identifiers and a destination for a given company.

PUT {api}/{version}/companies/{companyID}/patterns/{patternID}

Update an existing sorting pattern's identifiers or destination.

DELETE {api}/{version}/companies/{companyID}/patterns/{patternID}

Remove a sorting pattern from a company so it no longer affects document routing.

The supplier object now includes two additional tag properties that let you store additional identifying details on the supplier card.

We've added supplierTag5 and supplierTag6 to the supplier object, expanding the available tag properties from four to six. These new properties let you store additional identifying details — such as postal codes, addresses or reference identifiers — directly on the supplier card. AzoraOne uses tag content to match against document text, so populating these properties can improve retrieval accuracy where base data alone isn't sufficient.

Tag matching is a secondary mechanism. AzoraOne applies supplierTag values primarily when base supplier data is either identical across multiple records or missing entirely - tags don't replace base data matching. The text stored in a tag must match the text present in the document exactly for retrieval to work correctly.

Affected Operations:

POST {api}/{version}/companies/{companyID}/suppliers

Create a new supplier and populate supplierTag5 and supplierTag6 alongside any other supplier properties.

POST {api}/{version}/companies/{companyID}/suppliers/multiple

Create multiple suppliers in a single request, including values for supplierTag5 and supplierTag6 on each record.

GET {api}/{version}/companies/{companyID}/suppliers/{supplierID}

Retrieve a single supplier and inspect the full supplierTags object, including the new supplierTag5 and supplierTag6 properties.

GET {api}/{version}/companies/{companyID}/suppliers

Retrieve all suppliers for a company, with supplierTag5 and supplierTag6 included in each supplier object returned.

PUT {api}/{version}/companies/{companyID}/suppliers/{supplierID}

Update an existing supplier to add or modify values for supplierTag5 and supplierTag6.

Key Highlight:
The Retrieve file details endpoint now includes a new fileText object in the response. This object contains raw text extracted from the file using OCR and is controlled by the fileText query parameter. When set to true, the response includes the fileText object with the rawText property; when set to false (default), fileText object is returned with a null value.

Why it matters:
You can now access OCR-extracted text directly within the file details response, without needing to call a separate service.
This enables retrieving both the file and its extracted text in a single request. The extracted text can then be used for a range of use cases depending on integration needs, including downstream processing or analysis based on file content.

Example

{
 "fileText": {
   "rawText": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua."
 }
}

Affected Resource:
GET ...{api}/{version}/companies//files/{fileID}/details

Note: The fileText.rawText value is available only for files uploaded after 2025-10-08 00:00:00. Files uploaded earlier will still return the fileText object, but the rawText value will be empty.

Key Highlight:

The Retrieve all companies endpoint now supports two additional filters/query parameters:

• companyProxy (string) – allows filtering companies based on their proxy company.
• countryOfOrigin (string) – allows filtering companies by their country of origin.

Why it matters:

You no longer need to fetch the full list of companies and build your own filtering logic. You can now query directly for companies tied to a specific proxy or originating from a particular country. This provides you with smaller, more precise responses, improved performance, and simpler integration code on your end.

Affected Resource:

GET ...{api}/{version}/companies

Note: The response structure for companies remains unchanged. Only the filtering options have been extended, so existing integrations will continue to work without modification.

We’ve updated both GET /companies/{companyID} and GET /companies to optionally include file-processing metrics alongside core company data.

Key Highlights:

• Metrics Toggle: metrics=true returns overall counts (uploadedCount, extractedCount, bookedCount, extractedAndBookedCount, extractedByBricksCount)
• Type Breakdown: for each file type, returns type, averageConformity, extractedCount, bookedCount, extractedAndBookedCount
• Filtering: use fileCreatedFrom/fileCreatedTo (YYYY-MM-DD HH:mm:ss) and conformityFilters to scope metrics
• Pagination & Sorting: on GET /companies, control pageNumber, pageSize, sortField, and sortDirection

Why It Matters:
With the metrics toggle you get performance insights and statistics to build powerful dashboards, support tools, and audit workflows. You can even surface conformity results in customer-facing views to show how extraction is performing for them.

Sample Metrics Object

"metrics": {
          "files": {
            "uploadedCount": 1582,
            "extractedCount": 1566,
            "bookedCount": 1396,
            "extractedAndBookedCount": 1393,
            "extractedByBricksCount": 51,
            "types": [
              {
                "type": "SupplierInvoice",
                "averageConformity": 89.97,
                "extractedCount": 355,
                "bookedCount": 296,
                "extractedAndBookedCount": 296
              },
              {
                "type": "Receipt",
                "averageConformity": 78.23,
                "extractedCount": 1211,
                "bookedCount": 1100,
                "extractedAndBookedCount": 1097
              }
            ]
          }

Affected Resource:

GET ...{api}/{version}/companies/{companyID}

GET ...{api}/{version}/companies

Note: Detailed documentation is available at the endpoint level.

We’ve added a new GET endpoint that returns a file’s full lifecycle in one call—metadata, optional raw content, conformity score, and event history—so you can build rich “file details” pages without multiple requests.

Key Highlights:

• File & Content: retrieve all file properties, plus optional fileContent (Base64)
• Conformity Score: conformity toggle (with optional conformityFilter)
• Event History: eventSet selects between latestComparison or full eventHistory

Why It Matters:
This endpoint unifies file info, previews, performance metrics, history of extractions and bookings—fueling UIs and workflows with a single, efficient call. 

Example:

GET /v1/companies/42/files/abc123/details
   ?fileContent=true
   &conformity=true
   &eventSet=eventHistory

Resource:

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/details
   ?fileContent={boolean}
   &conformity={boolean}
   &conformityFilters={comma-separated fields}
   &eventSet={latestComparison|eventHistory}

Note: Detailed documentation is available at the endpoint level.

We’ve added a new GET endpoint that returns a paginated list of all files for a company, with powerful text search, filters, sorting, and performance insights, to drive dashboards, audit tools, or history views.

Key Highlights:

• Deep Text Search: Perform full-OCR searches across file contents
• Filters:  Narrow results by multiple available filters (e.g., type, status, date range)
• Performance Insights: Assess extraction accuracy and service quality
• Flexible Paging: Control pagination and view totals
• Aggregated Metrics: Analyse average conformity score for a set of files

Why It Matters:

Enables rich file-archive experiences with a single call—find any document by content, type, status, or date, and surface key performance metrics inline.

GET /v1/companies/42/files
    ?text=Petrol%20AND%20Coffee
    &fileCreatedFrom=2025-05-01%00:00:00
    &fileCreatedTo=2025-05-31%23:59:59
    &status=Booked
    &conformity=true
    &conformityFilter=amount,invoiceDate
    &summary=true
    &type=SupplierInvoice
    &sortField=CreatedDateUTC
    &sortDirection=desc
    &pageNumber=1
    &pageSize=20     

Resource:

GET ...{api}/{version}/companies/{companyID}/files[?text][&fileCreatedFrom][&fileCreatedTo][&conformity][&conformityFilter][&summary][&type][&status][&pageNumber][&pageSize][&sortField][&sortDirection]

Note: Detailed documentation is available at the endpoint level.

Two new properties, vatNumber and countryOfOrigin, are available on company and supplier resources—both in request bodies (POST/PUT) and in response bodies (GET)—alongside all existing properties.

Key Highlights:

• New JSON properties
  • vatNumber (string): the entity’s registered VAT identification number.
  • countryOfOrigin (string): the ISO 3166-1 alpha-2 code of the entity’s country of origin.
• Availability
  These new properties are available on company and supplier resources—in both request and response bodies—alongside existing properties.
• Validation behavior
  • If countryOfOrigin is unset, existing Swedish validation rules for corporateIdentityNumber apply.
  • If countryOfOrigin is set to another ISO code, that country’s validation rules apply—allowing non-Swedish corporate identity and VAT numbers.  
• Backwards-compatible
  Both fields are optional and default to an empty string ("") when unse 

Why It Matters

• Global onboarding: You can now add international companies without workarounds—simply specify countryOfOrigin to to switch validation rules.
• Compliance: Captures VAT IDs for reporting and cross-border invoicing.
   

Note: Detailed documentation is available at the endpoint level.

Affected Operations:

POST {api}/{version}/companies

GET {api}/{version}/companies/{companyID}

GET {api}/{version}/companies

PUT {api}/{version}/companies/{companyID}

POST {api}/{version}/companies/{companyID}/suppliers

POST {api}/{version}/companies/{companyID}/suppliers/multiple

GET {api}/{version}/companies/{companyID}/suppliers/{supplierID}

GET {api}/{version}/companies/{companyID}/suppliers

PUT {api}/{version}/companies/{companyID}/suppliers/{supplierID}

When you call the invoice or receipt extraction endpoints with ?extended=true, the response’s extended object will now also include additional country-specific identifiers found in the document. In addition to dates, emails and currencies, you’ll see: 

• Which country each identifier belongs to (via corporateIdentityNumbersByCountry and vatNumbersByCountry), 
• All extracted VAT numbers and corporate Identity Numbers organised by ISO country code,  
• And a single countryOfOrigin property indicating where the document most likely comes from. 

Example JSON

"extended": {
 "vatNumbersByCountry": {
      "SE": [
        "SE556600778601",
        "SE559108741501"
      ],
      "NL": [
        "NL001234567B01"
      ]
    },
    "corporateIdentityNumbersByCountry": {
      "SE": [
        "5566007786",
        "5020765649"
      ],
      "NL": [
        "12345678"
      ]
    },
    "countryOfOrigin": "SE",
 …
}

Affected resources:

GET .../companies/{companyID}/files/{fileID}/supplierInvoices

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/receipts
 

Description:
We’ve introduced a new PATCH endpoint to mark specific models as inactive. This feature helps ensure that only good models are used for document processing, improving accuracy and efficiency.

Key Highlights:

• Scope Control: Target models associated with an entire company, a specific file type (e.g., "receipt" or "supplierinvoice"), or even a particular supplier within a file type.

• Flexible Filtering: Use optional filters such as startDateTime and endDateTime to refine your updates.

• Supplier-Specific Logic: When targeting supplier-specific models, you must specify the type as "supplierinvoice."

Why It Matters:
Outdated models can introduce noise into document extractions. This feature ensures that only relevant and updated models are active, aligning AzoraOne with your company's evolving document extraction needs.

Example Use Case:
Deactivate all "supplierinvoice" models associated with Supplier X for a specific time frame.

New Resource:

PATCH ...{api}/{version}/companies/{companyID}/models[?type][&supplierID][&startDateTime][&endDateTime]

A new propertycreated is added to the responses of the GET progenitor/progenitors endpoints.

Impact:

The addition of the created property provides users with the ability to track when each progenitor was created, allowing for better sorting, filtering, and management of progenitor data based on creation timestamps.

• Retrieve All Progenitors:
  The data.progenitors array now includes a created parameter for each progenitor, which represents the timestamp when the progenitor was created.
  Example:

• {
    "success": true,
    "data": {
      "progenitors": [
        {
          "progenitorID": "1",
          "startDateTime": "2020-01-01 00:00:00",
          "stopDateTime": "2020-12-31 23:59:59",
          "supplierInvoices": true,
          "receipts": true,
          "created": "2024-09-01 10:51:28"
        },
        ...
      ]
    },
    ...
  }

• Retrieve a Progenitor
  The response now includes a created field under the data object, indicating the creation timestamp of the specific progenitor.
  Example:

  {
    "success": true,
    "data": {
      "progenitorID": "c1",
      "startDateTime": "2020-01-01 00:00:00",
      "stopDateTime": "2020-12-31 23:59:59",
      "supplierInvoices": true,
      "receipts": true,
      "created": "2024-01-30 09:00:28"
    },
    ...
  }
  

We've introduced a new feature that allows users to conveniently create multiple progenitors to a company with a single API request.

This enhancement maintains the existing functionality that the company will use inherited knowledge from the progenitor, while offering greater efficiency to include a list of progenitors when creating progenitors on a company. Please refer to the updated API documentation for more details on the new endpoint functionality.

ProgenitorList Object

{
    "progenitors": [{
        "progenitorID": "c1",
        "startDateTime": "2020-01-01 00:00:00",
        "stopDateTime": "2020-12-31 23:59:59",
        "supplierInvoices": true,
        "receipts": true
    }, {
        "progenitorID": "c2",
        "startDateTime": "2021-01-01 00:00:00",
        "stopDateTime": "",
        "supplierInvoices": false,
        "receipts": true
    }]
}

New resource

POST...{api}/{version}/companies/{companyID}/progenitors/multiple

There is new Origin object both on invoices and receipts that provide valuable information about ancestor type of the model and the company it belongs to.

Origin Object

{
    "success": true,
    "data": ...,
    "extended": ""
    "meta": ""
    "origin": {
        "ancestor": {
            "ancestorType": "None",
            "companyID": "23"
        }, 
    "time": "2020-07-28 11:41:02"
}

Affected resources:

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/receipts

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/supplierInvoices

There are two new dimensions; costBearer and resultsCentre on account item of both receipts and supplier invoices.

CostBearer

We have added the costbearer item to account item to allow extraction of costbearer data on both supplier invoices and receipts.

{
    "account": "1790",
    "periodicity": {
        "offsetAccount": "6210",
        "startDate": "2020-04-01",
        "endDate": "2021-03-31"
    }, 
    "costBearer": {
        "targetValue": "55555"
    },
    "debit": "2495,29",
    "credit": "0,00"
}

ResultsCentre

Additionally, resultscentre item to account item to allow extraction of resultscentre data on both supplier invoices and receipts.

{
    "account": "1790",
    "periodicity": {
        "offsetAccount": "6210",
        "startDate": "2020-04-01",
        "endDate": "2021-03-31"
    }, 
    "resultsCentre": {
        "targetValue": "1450"
    },
    "debit": "2495,29",
    "credit": "0,00"
}

Affected resources

PUT ...{api}/{version}/companies/{companyID}/files/{fileID}/supplierInvoices

PUT...{api}/{version}/companies/{companyID}/files/{fileID}/receipts

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/receipts

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/supplierInvoices

International Bank Account Numbers are now extracted along with the other extended information on both receipts and supplier invoices.

{
    "success": true,
    "data": ...,
    "extended": {
        "dates": [
            "2020-05-03",
            "2020-05-01",
            "2021-04-30"
        ],
        "times": [
            "11:23:55"
        ],
        "emails": [
            "info@arkimera.se"
        ],
        "currencies": [
            "SEK"
        ],
        "creditCardNumbers": [],
        "ibans": [
            "SE1150000000056241002716"
        ]
    },
    "meta": "",
    "time": "2020-07-28 11:41:02"
}

Affected resources:

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/receipts

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/supplierInvoices

The parameter invoiceNumber in the supplier invoice resource is no longer required. Feel free to send requests without it in the future!

Affected resources:

PUT ...{api}/{version}/companies/{companyID}/files/{fileID}/supplierInvoices

When AzoraOne is unable to locate a decimal value (received in the bookkeeping request) on a document, the service will (on APIs where rounding is enabled) try to find values within the rounding range of the value. This way, the values in bookkeeping request do not necessarily have to be identical to the values on the document, providing a bit of slack for the user when bookkeeping with AzoraOne. Which we refer to as approximation.

1. A rare case has been observed where AzoraOne has built models (based on approximated values) that will return two incorrect values in the extract response. This case has been observed only when the value has been bookkept both on the debit and credit side (i.e. in reversed sales tax). Its is now fixed.
2. When approximating with values on the credit side of accounts, AzoraOne would, in some cases, calculate the balance incorrectly. This would lead AzoraOne to conclude that the values found were not correct, and hence, these values (even if correct) would be removed from our response. This has been resolved as well.

We fixed an issue where some characters in file names could cause unwanted behavior. The service will no longer allow file names containing the characters below.

" | < >

The service will now return the following error message when these characters are present in the file name.

{
    "code": 211502,
    "message": "File name is not valid.",
    "details": "",
    "element": "file"
}

We have added the project item to account item to allow extraction of project data on both supplier invoices and receipts.

{
    "account": "1790",
    "periodicity": {
        "offsetAccount": "6210",
        "startDate": "2020-04-01",
        "endDate": "2021-03-31"
    },
    "project": {
        "targetValue": "P657588"
    },
    "debit": "2495,29",
    "credit": "0,00"
}

Affected resources:

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/receipts

PUT ...{api}/{version}/companies/{companyID}/files/{fileID}/receipts

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/supplierInvoices

PUT ...{api}/{version}/companies/{companyID}/files/{fileID}/supplierInvoices

We have added the precognition item to the company model. This allows you to extract supplier invoices using precognition knowledge.

{
    "companyID": "10",
    "companyName": "SmallCorp",
    "companyProxy": "Account Group Inc",
    "active": true,
    "precognition": {
        "active": false
    },
    "corporateIdentityNumber": "556754-9273",
    "bankAccountNumber": "310-6093",
    "plusGiroNumber": "477451-9",
    "iban": ""
}

Affected resources:

GET ...{api}/{version}/companies

POST...{api}/{version}/companies

GET...{api}/{version}/companies/{companyID}

PUT ...{api}/{version}/companies/{companyID}

We have added the periodicity item to account item to allow extraction of periodicity data on both supplier invoices and receipts.

{
    "account": "1790",
    "periodicity": {
        "offsetAccount": "6210",
        "startDate": "2020-04-01",
        "endDate": "2021-03-31"
    },
    "debit": "2495,29",
    "credit": "0,00"
}

Affected resources:

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/receipts

PUT ...{api}/{version}/companies/{companyID}/files/{fileID}/receipts

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/supplierInvoices

PUT ...{api}/{version}/companies/{companyID}/files/{fileID}/supplierInvoices

We have added a new resource that lets users delete all prior memories on a specific company.

This allows users to relearn the robot from the start, which can be useful when presenting demonstrations on how the robot learns.

New resources:

DELETE ...{api}/{version}/companies/{companyID}/memories

We have improved the accuracy when extracting data from the following XML-invoice types.

• Svefaktura 1.0
• PEPPOL BIS Billing 3.0
  • Invoice
  • Credit Note

With this update, basic information will be extracted even if the company has any previous memories. This behavior will be overwritten if the client bookkeeps the files differently.

Affected resources:

GET ...{api}/{version}/companies/{companyID}/files/{fileID}/supplierInvoices