Search
Getting Started Invoice sending Invoice sending Consumer Invoicing Printing Email invoicing Invoice receiving Invoice receiving Scanning Detect Fraud reporting Integration tools Webhooks Reference implementations Maventa Connector Embeddable User Interface Peppol Peppol Network Document Exchange Invoice Response Self-billing support Invoicing formats Invoicing formats Validation Peppol BIS 3.0 Finvoice 3.0 Document types and type codes Preview Maventa JSON (table) Preview Maventa JSON (json schema) Account management Companies and Settings Department Company Users Billing Accounts receivable Accounts receivable Ropo Reminder & Collection Amili Kassavirta Amili Perintä

Ropo Reminder & Collection

With Ropo Reminder & Collection, you can transfer overdue invoices to Ropo for reminder and debt collection.

Ropo handles reminder sending and all debt collection activities. The service is available in Finland, Sweden, and Norway, with additional countries such as Denmark and Germany planned (timeline TBD).

The service is provided by Ropo and delivered through Maventa as part of the Maventa service, with no separate usage fee. However, costs may arise in the later stages of the debt collection process. If a case proceeds to legal debt collection, any official authority fees incurred will be charged from the customer (service user). In addition, if the customer is VAT liable, Ropo will invoice the VAT portion of reminder and collection fees paid by the debtor. Costs may also occur if assignments are cancelled.

Ropo settles capital to the company’s account on a daily basis. Late payment interest is settled monthly as a single payment.

Once an invoice has been successfully transferred to Ropo, Maventa automatically creates an assignment. ERPs can track these assignments using the Receivables API, display assignment information to users within the ERP, report direct payments, or cancel assignments via credit invoices.

Opening the Ropo Reminder & Collection service

To activate the Ropo Reminder & Collection service, call PUT /v2/services/ropo/receivables. Use GET /v2/services/ropo/receivables to check the activation status.

Parameters for the PUT /v2/services/ropo/receivables call

Parameter Description
agreement_contact_email Email for a person authorised to act on behalf of the company. Used to send the request to sign the electronic agreement. Mandatory.

To complete the activation process, Ropo sends an email with a link to a wizard form to the address specified in agreement_contact_email. Through the wizard form, the recipient provides the required company details and electronically signs an agreement with Ropo.

The authorisation can be based on the individual’s role within the company or on a power of attorney, which must be attached to the form if applicable. Completing the form requires strong electronic identification (such as online banking credentials, Mobile ID, or BankID depending on the country).

Activation steps

  1. Wizard form — The invoicing company fills in the company details required to open a Ropo One profile. The form also collects the details of the contract approver (a person with signing authority). In Finland, the form additionally asks for a separate KYC form completer (also with signing authority), who can be a different person from the contract approver.

  2. KYC verification (Finland only) — After the wizard form is submitted, Ropo sends a KYC email link to the KYC form completer. The KYC form is a separate electronic form outside of Ropo One. In accordance with the Money Laundering Act, Ropo is required to identify its customers and understand their activities.

  3. User credentials — After the wizard form is submitted, Ropo sends the Ropo One user credentials.

  4. Agreement signing — The contract approver accepts the agreements the first time they log in to Ropo One. The service cannot be used until the agreements are signed.

  5. Service activation — Once the agreement is signed and verified by Ropo, the service is activated, typically within 1–2 business days. After activation, invoices can be transferred to Ropo for reminders and debt collection.

If the activation process is not completed within one week, Ropo sends a reminder email.

Transferring invoices to reminder and debt collection

Transfer overdue invoices to the Ropo Reminder & Collection service using the following API method:

POST /v2/invoices/{id}/assignment/ropo

Provide the invoice ID (UUID) for an overdue invoice along with the following parameters:

Parameter Required Description
collection_type Yes reminder_and_collection or collection
receivables_type Yes b2b, b2c, b2b_rental, or b2c_rental
amounts No Detailed breakdown of amounts (see below). Cannot be used in combination with collectable_amount.
payers Yes Array of payer objects (see below)
reminder_date When collection_type = collection Date (YYYY-MM-DD) when the reminder was sent by the sender
assignment_summary Yes Description of what the assignment refers to (see below)

Duplicate invoice numbers are not allowed. Ensure that each invoice number is unique, avoiding any reuse.

B2B invoices can be transferred 7 days after the due date. B2C invoices can be transferred 14 days after the due date.

Collection_type

Amounts

Capital, costs, and interest must always be reported separately. They must not be combined into a single capital amount.

Field Required Description
capital_amount Yes Amount of capital invoiced. Must be a positive number (e.g. 100.50).
reminder_amount Yes Amount of reminder fees invoiced. Must be a positive number (e.g. 5.00).
interest_amount Yes Amount of previous interest invoiced. Must be a positive number (e.g. 10.50).
interest_calculation_date No Date (YYYY-MM-DD) from which to start interest calculation, for cases where interest has been collected before assignment creation.

Payers

Each payer in the array requires the following fields:

Field Required Description
type Yes main_debtor or co_debtor
name Yes Payer’s full name
bid For b2b and b2b_rental Business ID
ssn Required for b2c_rental Payer’s social security number, used for the legal collection process
address Yes Address object (see below)

Address fields

Field Required Description
line1 Yes Street address
line2 No Additional address line
post_code Yes Postal code
city Yes City
country Yes Country code

Main debtor and co-debtor details must be provided separately in the API. For consumer rental receivables (b2c_rental), the payer’s SSN is mandatory — if SSN is missing, the assignment cannot be transferred to Ropo.

The debtor’s full address must be provided. If any address details are missing, the invoice cannot be forwarded to Ropo.

Assignment_summary

Provide a specific description of what the assignment refers to:

Transfer status

The final endpoint URL for checking the transfer status is not yet confirmed and may change between v1 and v2.

Check the status of the transfer using GET /v1/invoices/{id}/assignment:

Possible errors

If the invoice is not yet past due, the API returns a 400 error:

{
  "code": "invalid_parameters",
  "message": "Request parameters are invalid",
  "details": [
    "Invoice not expired"
  ]
}

Creating assignments manually

Invoices that have not been sent through Maventa can also be transferred to the Ropo Reminder & Collection service by creating an assignment manually.

To do this, create the invoice using POST ​/v1​/invoices with the prevent_routing parameter set to true. This marks the invoice immediately as SENT without actually delivering it to the receiver. After the invoice is created, use the Ropo Reminder & Collection APIs described above to transfer it to the reminder and/or debt collection process.

Creating assignments manually will have a debit action and it will be billed according to the existing price lists.

Reminder and debt collection schedule

When an invoice is transferred for the reminder and collection process, Ropo sends the first reminder 10 days after the due date for B2B invoices and 14 days after the due date for B2C invoices. If the invoice is transferred directly to the collection process, a payment demand is sent first.

Letters are not sent during weekends or public holidays, which may add a few additional days to the schedule in some cases.

Delivery method of reminders and collection letters

The delivery method depends on the country and how the original invoice was delivered.

Finland

Norway and Sweden

You can find the detailed and most up-to-date schedule on Ropo’s website:

Language of the reminder and debt collection letters

The language used for reminders and debt collection letters is determined from the invoice data:

  1. POST /v1/invoices parameter lang
  2. Invoice format language field (e.g. Finvoice InvoiceRecipientLanguageCode)
  3. If not defined explicitly, the language defaults based on the sender’s country

Assignments

For each invoice transferred to Ropo Reminder & Collection, Maventa creates an assignment. The assignment allows the company to follow up on the collection process and serves as a communication channel between the sender and the collection agency.

To link the sent invoice and the assignment together, the assignment contains reference_ids including invoice_id with the UUID of the original invoice.

If Ropo needs information or action from the sender before they can continue processing an assignment, they put the assignment on hold and contact the sender by email. The assignment continues once the matter is resolved.

An assignment can have one of the following statuses:

  1. Open — The assignment is active and Ropo handles the reminder sending and debt collection process depending on the chosen collection type.
  2. Closed — The assignment is closed. The invoice has been paid and no charges are open. Ropo has transferred the money to the company’s account.

Assignment content

Parameter Description Applicable to Ropo Reminder & Collection
id Assignment ID
status Open (unpaid) / closed (paid or cancelled) / partially_closed partially_closed status does not exist with Ropo
collection_status Collection status of the assignment. Set based on events added by the agency.
service_level default (normal process) / premium / vip. Does not apply to Ropo, always default with Ropo
debtor name: Name of the customer (receiver of the invoice) and bid: customer’s business ID
due_date Due date from the original invoice
issued_at Invoice date from the original invoice
number Invoice number from the original invoice
sum Total sum of the invoice (taken from the invoice data if not given in the API when transferring the assignment)
paid Amount that is paid or credited
currency Currency from the original invoice
created_at When the assignment was created
updated_at When the assignment was last updated (e.g. when the paid sum was updated)
partially_closed_at When the assignment was partially closed
closed_at When the assignment was closed by Ropo
reference_ids Contains three IDs: agency_id = Ropo ID, invoice_id = ID of the original invoice (UUID), number = reference number from the original invoice

JSON example of an assignment and its event

[
  {
    "id": "fa9781ba-20d1-4677-a125-f04bff7bbac0",
    "status": "open",
    "collection_status": "reminder_sent",
    "service_level": "default",
    "debtor": {
      "name": "Test receiver Oy"
    },
    "due_date": "2020-04-20",
    "issued_at": "2020-04-01",
    "number": "64488",
    "sum": 12.3,
    "paid": 10,
    "currency": "EUR",
    "created_at": "2020-04-15T05:47:07Z",
    "partially_closed_at": null,
    "updated_at": "2020-04-15T21:01:18Z",
    "closed_at": null,
    "reference_ids": [
      {
        "type": "agency_id",
        "value": "078dbb88-ef8e-4115-8260-c8a542aaa87c"
      },
      {
        "type": "invoice_id",
        "value": "f6dcf18d-a1bd-4e72-bb8a-80908527b6c8"
      },
      {
        "type": "number",
        "value": "356241887794"
      }
    ],
    "events": [
      {
        "id": "c0c56722-a28b-49d1-aa87-1c4d7f3cf1af",
        "type": "paid",
        "data": {
          "sum_paid": 10,
          "booked_at": "2020-04-16",
          "archive_number": "12345"
        },
        "party_id": "938fc79f-9c00-47af-8507-cdf15838aa96",
        "seens": [
          {
            "seen_at": "2020-04-15T22:00:06Z",
            "seen_by": "938fc79f-9c00-47af-8507-cdf15838aa96"
          }
        ],
        "created_at": "2020-04-15T21:01:18Z",
        "happened_at": "2020-04-16T00:00:00Z"
      }
    ]
  }
]

Receivables API for assignment handling.

Collection status of the assignment

collection_status Events that set the collection status
unknown Default value until a reminder is sent or collection activities are started
reminder_sent reminder_sent / second_reminder_sent
debt_collection collection_started (first payment demand is sent) / second_demand_sent / tratta
legal_collection legal_collection_started
recovery_proceedings application_for_enforcement
debt_surveillance credit_loss_suggestion (note: the credit_loss event does not change the collection status)
lack_of_means lack_of_means
payment_plan payment_plan

Events

Events are added to assignments once something happens on the Ropo side, such as a payment made by the debtor. The sender can also add events to communicate information to Ropo, like direct payments to the sender’s own account or a request to credit the invoice.

Automating these events from the ERP is highly recommended. At minimum, automate paid and credit_note events to ensure they are always communicated to Ropo without relying on end users to remember to do this manually.

Receivables API for event handling.

Events added by Ropo

Event type Description
reminder_sent Reminder has been sent to the debtor
second_reminder_sent Second reminder has been sent
collection_started First payment demand sent, debt collection begins
second_demand_sent Second payment demand sent
tratta_sent Tratta sent (B2B)
legal_collection_started Legal collection started
application_for_enforcement Application for enforcement filed
lack_of_means Enforcement authority has declared the debtor insolvent
payment_plan Payment plan agreed with the debtor
paid Payment received by Ropo
close Assignment closed by Ropo

Events added by the sender

Event type Required fields Description
paid sum_paid, booked_at Direct payment received on the company’s own account
credit_note credit_sum, booked_at Credit the assignment to cancel it
credit_loss   Mark the assignment as a credit loss

Event details

Handling payments

paid – Used to report payments made by the customer and to notify direct payments.

Usage scenarios:

  1. Customer payment through Ropo. Ropo sends a paid event when the customer pays the assignment, either fully or partially.
  • If the assignment is fully paid, Ropo will automatically close it (close event added).
  • If the customer pays more than the invoice amount, the excess is refunded to the customer. Ropo does not retain overpayments for future invoices.
  1. Reporting direct payments Use this event to inform Ropo when the customer pays directly to the sender company’s account. Payments may be full or partial.
  • If additional details are needed, they can be provided using a comment event.
  • If the assignment is fully paid, Ropo will close it (close event added).

It is very important that direct payments are reported through this event so that Ropo can update the open balance or close the assignment correctly. Automating this event in the ERP is strongly recommended to ensure direct payments are always reported.

The paid event updates the paid field in the assignment, but does not modify the sum value.

{
    "type": "paid",
    "data": {
      "sum_paid": 200.5,
      "booked_at": "2019-01-04",
      "archive_number": "12345"
    }
  }

Both the company and Ropo can create this event type.

Closing an assignment

close – Ropo uses this event to mark an assignment as closed. An assignment is closed when any of the following occurs:

  • the customer has fully paid the assignment
  • you report that it has been fully paid (direct payment)
  • you report that it has been fully credited
  • you request cancellation of the assignment

Once closed, no further collection activity is carried out for that assignment.

Only Ropo can create this event type.

Connecting a credit note to an assignment

credit_note – Use this event to link a credit note to an assignment. Provide the credit note number and the credit sum when sending this event. The credit sum should be entered as a positive value.

  • If the credit note fully covers the assignment, Ropo will close the assignment (close event added).
  • If only part of the assignment is credited, Ropo will continue monitoring payments and follow the debt collection process for the remaining amount.

Automating this event in your ERP is strongly recommended to ensure that a credit_note event is always sent when credit notes are created.

Only the company can create this event type.

When the first reminder is sent to the customer

reminder_sent – Ropo adds this event when the first payment reminder for an unpaid invoice has been sent. If the assignment’s collection_status is not already set to reminder_sent, the event will update it accordingly.

Only Ropo can create this event type.

When the second reminder is sent to the customer

second_reminder_sent – Ropo adds this event when the second payment reminder for an unpaid invoice has been sent. If the assignment’s collection_status is not already set to reminder_sent, the event will update it accordingly.

Only Ropo can create this event type.

When the first payment demand is sent to the customer

collection_started – Ropo adds this event when the first payment demand for an unpaid invoice has been sent. If the assignment’s collection_status is not already set to debt_collection, the event will update it accordingly.

Only Ropo can create this event type.

When the second payment demand is sent to the customer

second_demand_sent – Ropo adds this event when the second payment demand for an unpaid invoice has been sent. If the assignment’s collection_status is not already set to debt_collection, the event will update it accordingly.

Only Ropo can create this event type.

When the tratta is sent

tratta_sent – A tratta has been issued for an unpaid invoice. This event will update the assignment’s collection_status to debt_collection if it has not already been set.

Only Ropo can create this event type.

Legal collection is started

legal_collection_started – A summons application has been submitted and the legal collection process for the assignment has begun. This event will update the assignment’s collection_status to legal_collection.

When legal collection is required, Ropo requests your confirmation before proceeding.

Only Ropo can create this event type.

An application for enforcement is sent

application_for_enforcement – An application for enforcement has been submitted and the assignment has been transferred to the enforcement authority. This event will update the assignment’s collection_status to recovery_proceedings.

Only Ropo can create this event type.

The enforcement authority has found the debtor insolvent

lack_of_means – The enforcement authority has declared the debtor insolvent. This event will update the assignment’s collection_status to lack_of_means.

Only Ropo can create this event type.

A payment plan has been agreed on the invoice

payment_plan – A payment plan has been agreed on the invoice. This event will set the collection_status of an assignment to payment_plan.

Only Ropo can create this event type.

Marking an assignment as credit loss

credit_loss – You can mark the assignment as a credit loss for accounting purposes. Reporting a credit loss does not affect payment control or monitoring, and Ropo will continue the collection process as usual.

Once submitted, a credit loss entry cannot be reversed or modified.

Only the company can create this event type.

Closing the service

Ropo Reminder & Collection can be closed by calling DELETE /v2/services/ropo/receivables. Ropo will still handle any open assignments.

Even after closing the service, the APIs remain available for following up on remaining open assignments and adding events as needed.

Back to top

AI Chat Support 24/7

  • Get help via AI chat available 24/7 whenever it suits you
  • Chat extensively uses Maventa support pages, websites, and blogs in its answers
  • If you need assistance that the AI cannot provide, you can also ask a customer service agent to join the conversation
  • Support requests processed Monday to Friday
Cancel Open chat

Got feedback?

Did you not find what you were looking for? Or was something explained unclearly? Or just want to share your thoughts? We are happy to hear your feedback!

Note: This form is not a way to get support, this is only for feedback for the documentation website. If you need support, please contact Maventa support.

Integration Guide Services & Reach API Specification Changelogs Integration guide Getting Started Invoice sending Consumer Invoicing Printing Email invoicing Invoice receiving Scanning Detect Fraud reporting Webhooks Reference implementations Maventa Connector Embeddable User Interface Peppol Network Document Exchange Invoice Response Self-billing support Invoicing formats Validation Peppol BIS 3.0 Finvoice 3.0 Document types and type codes Maventa JSON (table) Maventa JSON (json schema) Companies and Settings Department Company Users Billing Accounts receivable Ropo Reminder & Collection Amili Kassavirta Amili Perintä Services and reach Maventa services and reach e-invoicing in Finland Mass Printing Service e-invoicing in Sweden e-invoicing in Norway e-invoicing in Denmark e-invoicing in the Netherlands e-invoicing in Belgium e-invoicing in Germany e-invoicing in Estonia e-invoicing in Latvia e-invoicing in Poland e-invoicing in Italy e-invoicing in France e-invoicing in Spain Api specification API overview Getting Started Common & authentication API Invoices API Documents API Companies & settings API Lookups API Detect API Validator API Receivables API Billing API Scanning API B2CFI API B2CNO API B2CSE API Partner API Getting Started API Methods Overview Account Configuration API Methods Invoice Sending API Methods Invoice Receiving API Methods B2C Norway API Methods B2C Finland API Methods Other API Methods Changelogs Product changelog Developer Changelog
Clear Send

Enter your credentials to Maventa testing environment, to authenticate and try things out with the Swagger UI. This will fetch a Bearer token using OAuth2 with the endpoint POST https://ax-stage.maventa.com/oauth2/token. The token is stored in your browser's session storage (cleared when you close the tab) and used in Swagger calls done from this documentation website. The token is valid for 1 hour.

Never use your production credentials here. This is only for testing the Maventa test environment in the Swagger UI.
Reset All None
eui global company lookup document:receive document:send invoice:receive invoice:send company:read company:write validate receivables:assignments analysis billing:reports partner:invoice_delivery_actions partner:lookups partner:takeovers partner:lyanthe_scan_service fi_bank_message:send fi_bank_message:receive
Cancel Sign In