Ropo Reminder & Collection
With Ropo Reminder & Collection, you can transfer overdue invoices to Ropo for reminder and debt collection.
- B2B invoices can be transferred 7 days after the due date.
- B2C invoices can be transferred 14 days after the due date.
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
-
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.
-
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.
-
User credentials — After the wizard form is submitted, Ropo sends the Ropo One user credentials.
-
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.
-
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
- reminder_and_collection — transfer the invoice to a full reminder and debt collection process
-
collection — transfer the invoice directly to the collection process when you have already handled the reminder sending yourself. When using this type,
reminder_dateis mandatory.
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:
- Avoid vague descriptions like “purchase of groceries” or “goods”
- Use clear terms, e.g. “purchase of umbrellas”
- “Worked hours” is acceptable
- Row description from the invoice can be used as an alternative
- If several services are invoiced together, specify them clearly: “waste management services & water/sewage fees”
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:
- Pending — Waiting for the transfer
- Sent — Transfer successful and an assignment has been created. The response also contains a link and assignment id to the newly created assignment.
-
Error — Transfer failed. The most common reason is missing receiver address details. Error reason is visible in
error_reasonfield.
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
- B2B — Reminders and collection letters are sent electronically to the same delivery address as the original invoice (e-invoice or email). If the original invoice was sent by post, or if the electronic delivery route is no longer available, the letters are sent by post.
- B2C — Always sent by post.
Norway and Sweden
- If the original invoice was sent by email, reminders and collection letters are also sent by email.
- In all other cases, they are sent by post.
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:
-
POST /v1/invoicesparameterlang - Invoice format language field (e.g. Finvoice
InvoiceRecipientLanguageCode) - 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:
- Open — The assignment is active and Ropo handles the reminder sending and debt collection process depending on the chosen collection type.
- 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 |
|
| 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:
- 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 (
closeevent 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.
- 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 (
closeevent 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 (
closeevent 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.