Add a Status to a Matter

Article

Participants on a record can keep up-to-date with activity on a matter via the Status App. You can add a status to any matter via the Add Status Button under More Actions on a Matter’s View Page.                

How to Request a Status Update from a Vendor

Article

You can request a status update from vendors assigned to a matter via the Request Status Update from Vendors button under More Actions on a Matter’s View Page.                

Legal Entities

Article

The Legal Entities App is used to capture a client’s various legal entities that are associated with matters for e-billing. Each record in the Legal Entities App creates an associated legal entity in BillingPoint. The name, address, and tax ID for a matter’s legal entity will display on the Billing Authorization Request in BillingPoint and instructs the vendors which legal entity they should bill to for a particular matter. This information is maintained on the individual Legal Entities Records (in Onit), within Fields. A Legal Entities Record can be in either a New, Active, or Inactive Phase. Only Active legal entities are available to choose from on a matter.

The following Fields are required in the Legal Entities App and should not be deleted:

Onit Matter Taxonomy

Article

For most implementations, all matters will have a three-tiered matter taxonomy field set:

• area_of_law
  • matter_type
    • matter_subtype1

All of the fields above will be dropdowns. The available matter_type dropdown options will be dependent on the selected area_of_law; the available matter_subtype1 dropdown options will be dependent upon the selected matter_type.

Below are some screenshots that show the matter taxonomy approach described above.

The matter_type dropdown:      

Release Notes - May 2020

Article

• We've added new options to the Action Set Delegates For User, so that the delegate need not see the delegator's Records when filtering by My Transactions or My Pending Work.
• App creators are now prevented from saving duplicate Field tags.
• Update Transaction Actions that set Multiselect Fields can now do so using JSON format.
• When a system admin goes to the Deleted Transactions node in an App's Designer, they can now see who did the deletion.
• When automatic daily jobs encounter an error, they now log the error and try to keep going, instead of just stopping.
• System administrators can now cancel daily jobs from within the UI, or set failed ones to try again.

Welcome to BillingPoint Release Notes

Article

Welcome to ELM Release Notes

Article

Accounts Payable Integrations

Article

After an invoice has been fully approved and validated, Onit typically hands it over to an Accounts Payable Team and/or system to pay. There are multiple ways to facilitate this exchange:

• Flat-file Integration: This is the most common and recommended integration style. Using an SFTP server, Onit exchanges flat-files with a client. Onit generates an “invoices to pay” flat-file which the client consumes; the client generates an “invoices paid” flat-file which Onit consumes. In most cases, flat-files are generated and consumed using ETL jobs or other middleware tools.
  
• API-based Integration: Though less common, it is possible to exchange invoice data via APIs. Onit can initiate calls to an Accounts Payable system’s API and/or the AP system can make calls against Onit’s RESTful API.
  
• Email-based Integration: In a small number of cases clients prefer that Onit only send emails to an Accounts Payable Team, listing the invoices that should be paid. This is often done in place of a more robust flat-file or API integration.

After the Invoices Record is fully approved and validated, a new Record will be created in a separate child App named Invoice Payment. All integration jobs that facilitate sending payments to an Accounts Payable Team/system will exclusively interface with Records in the Invoice Payment App – integration jobs should never interface directly with Records in the Invoices App.

Throughout the payment process, the Invoices App and Invoice Payment App’s Phases stay in lock-step with respect to Phases (this is done using configuration that already exists in the environment). Any Phases that follow your custom approval process (i.e., Phases Approved through Paid) should not be edited or deleted; also, none of the Phases in the Invoice Payment App should be edited or deleted.

Invoice Validation

Article

After an invoice has been fully approved, it is highly recommended that you run validations against it, before the invoice is sent off for payment. For example, you may want to validate that the sum of all allocations equals 100%, or that the invoice maps to an Office Record that contains an Accounts Payable ID. While the specific validations that should be performed will vary from client to client, the primary goal is to catch any data issues that may prevent an Accounts Payable Team from actually paying the invoice.

The environment does not provide any pre-configured invoice validations – these must be configured into the Invoices App for each implementation. It is a best practice to run validations during the Approved Phase. When an invoice fails its validations, the invoice should be configured to move to the Held Phase, where notifications of missing data or errors should be sent out to the appropriate Participants, asking them to resolve any issues. In many cases you’ll want to add a Resubmit Button for end-users to click after they fix a “held” invoice (clicking this Button should re-run any validations).

Adding Invoice Allocations

Article

Upon creation of an Invoices Record in Onit, all allocations that have been added to the parent Matter Record will be automatically duplicated to become children of the Invoices Record.

Using the default configuration, changes made to allocations on a Matter Record have no effect on allocations assigned to existing Invoices Records. In other words, if an end-user adds, deletes, or modifies allocations while viewing a matter, those changes will not apply to allocations that are assigned to any existing invoices – those changes will only apply to future invoices that have yet to be submitted.